Inspire, develop, and guide a winning organization.
Create visible workflows to achieve well-architected software.
Understand and use meaningful data to measure success.
Integrate and automate quality, security, and compliance into daily work.
Understand the unique values and behaviors of a successful organization.
Explore our extensive library of experience reports.
An on-demand learning experience from the people who brought you The Phoenix Project, Team Topologies, Accelerate, and more.
Learn how making work visible, value stream management, and flow metrics can affect change in your organization.
Multiple award-winning CTO, researcher, and bestselling author Gene Kim hosts enterprise technology and business leaders.
In the first part of this two-part episode of The Idealcast, Gene Kim speaks with Dr. Ron Westrum, Emeritus Professor of Sociology at Eastern Michigan University.
In the first episode of Season 2 of The Idealcast, Gene Kim speaks with Admiral John Richardson, who served as Chief of Naval Operations for four years.
The conference for leaders of large, complex organizations. Attend our flagship event in Las Vegas!
We’re still working on dates for our Europe-based 2024 event. Stay tuned! Registration is not open.
The conference for leaders of large, complex organizations. Registration is not open.
Since 2014, you’ve asked for a way for this community to interact between conferences. Well, we’re finally making it happen.
DevOps best practices, case studies, organizational change, ways of working, and the latest thinking affecting business and technology leadership.
Gene Kim shares his programming highlights for our upcoming conference.
Could right fit help talent discover more meaning and satisfaction at work and help companies find lost productivity?
The values and philosophies that frame the processes, procedures, and practices of DevOps.
This post presents the four key metrics to measure software delivery performance.
March 30, 2021
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
No comments found
Your email address will not be published.
First Name Last Name
Δ
The following is an excerpt from the book Industrial DevOps: Building Better Systems Faster…
This post is adapted from the DevOps Enterprise Forum paper "Talking Business: Understanding Business…
As our longtime audience will know, each year we hold the DevOps Enterprise Forum,…