Project to Product Transformation Case Study: Global Media Service Provider

The case concerns a multinational corporation providing business support systems via a SaaS model (SaaS-based multi-tenant back end). Their most important product is customer care systems to large service companies in the healthcare and telecommunications markets. The company is by design product-centric (workforce management, customer care, billing, order management, messaging). It is heavily standardized, but products are customized for larger customers. This foundation made the scaling and sustenance of the project to product transition much more manageable.

Transformation Implementation

The project to product transformation was built upon a DevOps organization that had already existed for several years. This provided a solid base of expertise, and each DevOps team was already aligned to product teams in the business. As the project to product shift took shape, several modifications were made to the organization. The 500-strong engineering team, 200-strong operations team, and further 200 IT professionals were merged into a single organization. This brought together the build and run competences, and further strengthened the focus on the product.

A more difficult transition was moving away from a more traditional PMO to a portfolio leadership group. In fact, this only happened after the CIO was replaced. In the new setting, the project management capability is embedded in the product group. In addition to project management, the group also looks at investment and the communication plan. Moving away from the old mental model required a lot of “soap boxing” to sell the new journey.

As our interviewee stated, “We realized that this wasn’t just a change of nomenclature. It’s also behaviors and ownership. When you switch to a product focus, you are paying for a product backlog in perpetuity until you sunset the product. That’s a different mental model than a project that you start, drive to completion, have a budget, etc.”

The company now has only three or four project managers who oversee massive epics that cross many teams and usually involve customers. For example, a recent improvement needed intensive coordination with customers to upgrade 30,000 external connections. Although the work on the back end was reasonable, it took a long time. Project managers worked on this project for over eighteen months.

Business and Technology Synchronicity

As a product company, there is a dominant product management group. The chief product officer (CPO) owns the investment (about $500 million annually) for the product portfolio. Each product has its own profit and loss statement. All funding comes through the CPO.

In the scaling phase, the customer sales group served as the first line of defense to intake work. The group talked to product managers and coordinated backlog feature requests. The company had already completed a DevOps transformation, which included creating a single backlog for all work. This needed to be modified as it was found that a product manager tends to focus on new features, and as a result, can struggle to incorporate all “other” types of work, such as technical debt and incidents. To create a sustainable scale, the work types needed to be standardized.

Part of the transition was to understand what all the different work types were and then create one backlog for all work. It was crucial that product managers on the business side became aware of and appreciate all the work—incidents, backlog, etc.—and that it was brought together and made visible. Much effort was expended to consolidate work management systems and to make sure that data was replicated between systems. Today, the product development teams control everything except for platform infrastructure and corporate applications, which reside with the CIO and corporate IT.

To sustain the new approach, another critical change was made. Every epic that comes in must have a business case to gain funding. Across the portfolio, work in progress is managed at the epic level. Service requests and incidents also come in. When the work was analyzed, it was found that work on incidents absorbed 40% of capacity. Even today, it is a continuing challenge to decide whether to do 40% less work or even 80% less work to eradicate those incidents.

The advantage these days is that it is all managed through a single system, which was obviously not the case during scaling. Impact assessment is used to analyze each team’s work capacity to ensure that teams are not overloaded. The same practices are used across the entire organization. This enables and is enforced by a lean portfolio group. The build toolchain is treated as a product and managed by a specific team. To underpin this way of working, engineering has become a core competence. This enterprise no longer uses contractors.

Product Taxonomy

As a product-focused organization by nature, taxonomy has always been standardized in all of the enterprise’s market areas: workforce management, customer care and billing, order management, and messaging.

Architecture

The core architecture is SaaS-based with a multi-tenant back end. The earlier DevOps transformation drove most of the architectural changes, such as self-service and API-first design. In the scale and optimize phases, it was essential to avoid handoffs and create service-level agreements to maintain the integrity of the value stream.

The relationship with the enterprise team has evolved. Architecture patterns could be pushed to the platform team as it grew from a more traditional IT function. This helped the enterprise move away from ticketing systems and toward self-service. It also started to treat what it was doing as a product, as an investment, and as a service. Now, when the enterprise chooses to take on a new project, the enterprise performs an “impact assessment” that analyzes the project’s architecture dependency. This happens every quarter. The enterprise plans which teams are involved, what platforms are required, etc. for each project.

In the previous phase, the ITIL was utilized. It was found that a lot of ITIL processes were very activity- and project-focused, not product-focused. Currently, the enterprise does not use ITIL-based change management for this. Change management is limited to production collision management.

Funding Model

The most essential change in the optimize phase is the funding model. Because the product model depends on teams being aligned to the products they build and run, it is crucial that as much of the spend as possible is also aligned to product. This means the product portfolio group looks at the overall investment plan. The decisions at the portfolio level are made annually. The chief product officer owns investment for the product portfolio and controls funding. Every year, decisions are made at the portfolio level about where to invest. There is an intake process based on epics. Each epic is funded independently.

Epics are presented every two weeks. Every Friday afternoon for ninety minutes the epics are proposed. All product groups “compete” in these meetings. There are politics, of course; since product managers control the funding, they have significant influence over how the epics are assigned. It is vital to convince product managers of the virtues of each epic. Some epics are rubber-stamped because they already align with a product manager’s strategy, while some are approved because the epic is mandatory. Everything passed gets visibility in that meeting.

The business case might not always be monetary; it could instead be employee satisfaction, customer experience, or reduction in hours. In this way, all products have P&Ls (profit and loss statements). Each product manager gets a slice of the funding pie. In this scenario, corporate IT is treated as a product. This has resulted in 90% of spend aligned to product.

One area that still needs refinement is charge-back for specific products. In theory, time is charged back to particular products, but it doesn’t work that way in reality. Because the cost structure looks exactly like the product layout, it would probably be better to get rid of chargebacks, but there’s still some resistance.

Culture and Leadership

As mentioned earlier, product/business alignment was already well understood in the enterprise. This meant that the business didn’t need to make many changes as project to product was scaled out. However, it was essential to extend the product focus to IT professionals who focus on the back-end systems. Enterprise IT lacked a dependable product management organization.

Instead, the organization was run through projects and project managers, but that’s very different than product management. Project managers tend to be more mission-focused and tend to look less interested in investment ROI or spend. As the company started shifting to a product-centric model, they pivoted the focus toward product management, starting to treat each product group as the CEO of their product line.

Another change concerned operational service level objectives. In the previous phase, SLOs (service-level objectives) were viewed as a concern only for operations—operations owned SLAs/SLOs. These are now shared across product, engineering, and sales. Everyone shares the same objectives and goals. For example, if there is a target of 200 minutes downtime and it is exceeded, everyone feels the pain. Part of making all the work visible to all the stakeholders is that everyone needs to understand concepts like uptime and mean time to recovery. There was initial pushback from some stakeholders who felt that they didn’t need to understand the role of operational aspects on overall cost, efforts, etc. That has been overcome.

Reflection

It was easy for this enterprise to holistically transition from a project to a product focus due to the existing product focus at its core. It was also advantageous that an expansive adoption of DevOps had already occurred.

Even so, the long-term sustainability of the project to product transition has required a change in the funding model so that 90% of all technology spend is aligned to business-recognized products. This requires a strong chief procurement officer, value stream thinking, and vulnerability to suggest and defend epics to business product owners in a competitive environment.

Other areas that needed to be overhauled to cement the long-term success of their project to product transformation include calibrating project management capabilities and diluting the emphasis of ITIL support processes to collision management.

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

• Seven Domains of Transformation
• Transformation Implementation
• Business and Technology Synchronicity
• Product Taxonomy
• Workforce and Talent
• Funding Model
• Architecture
• Culture and Leadership

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

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 Revolution on Social Media

• 
• 
•