The IT Operating Model Question Most CIOs Avoid
McKinsey's Global Tech Agenda 2026 found that only one in ten top-performing companies has fully adopted product and platform models across all of their IT teams, though that is more than four times the rate of other organizations. Nearly half of these top performers have at least half their teams operating in a product model. CIO.com's May 2026 analysis confirmed that many CIOs have yet to move their IT operations from a conventional project-based structure to one focused on products or value streams.
The CIOs who have not made this move are not unaware that the project model is creating problems. Most of them can articulate the problems clearly: projects get funded, completed, and disbanded, leaving no team accountable for the capability after go-live. The business waits for the next project cycle to get changes that should take weeks. IT resources are constantly being assembled and disassembled across project teams rather than building deep capability in stable teams. The governance is around delivery rather than outcomes. The business does not feel like IT is a partner; it feels like a vendor that quotes timelines and budgets rather than a team working toward the same goals.
The question of whether to restructure the IT operating model around products or value streams rather than projects is the question most CIOs know they should be asking and most of them avoid. The avoidance is rational: the answer requires organizational changes that are uncomfortable, require renegotiating authority structures with business leaders who are accustomed to the current model, and have no clean implementation timeline that fits neatly into an annual planning cycle. The cost of avoiding the question is the compounding organizational inefficiency described above. The cost of answering it incorrectly, by restructuring the IT function without building the organizational conditions that make the new model work, is a disruptive transformation that reproduces the old problems in a new structure.
Why the Project Model Produces the Problems CIOs Are Experiencing
The project model was designed for a specific organizational context: one where technology investment was episodic, where systems once built required minimal change, and where the primary governance question was whether a project was delivered on time and on budget. In that context, organizing IT around projects made sense. You fund a project, you resource it, you deliver it, you disband the team and reallocate the resources to the next project.
The organizational context in which most enterprises operate IT in 2026 does not resemble that model. Systems require continuous improvement rather than episodic delivery. Customer expectations, competitive dynamics, and regulatory requirements change continuously. AI programs require ongoing model management, data governance, and operational monitoring. The capabilities that matter most to business outcomes need to be continuously evolved rather than delivered once and maintained. In this context, the project model produces the problems CIOs experience because it was designed for a different kind of work.
The project model's specific failure modes in the current environment are well-documented. The accountability gap: the team that built the system is disbanded after go-live, leaving the team that inherits it without the knowledge of why decisions were made, which tradeoffs were accepted, and which technical debt is structural versus incidental. The prioritization friction: every change to a live system requires a new project request, approval, funding, and team assembly, creating a queue for changes that should take days but take months. The alignment gap: the business leader who sponsored the project is no longer actively engaged after delivery, and the IT team maintaining the system has no direct connection to the business outcomes the system was supposed to support. And the capability dilution: generalist project teams assembled for a specific delivery do not develop the deep capability in specific technical or business domains that stable, long-lived product teams build over time.
What the Product Model Actually Changes
The shift from a project model to a product model is often described as an organizational change and resisted on organizational grounds. It is more accurately described as an accountability model change: the question shifts from "did we deliver the project?" to "is the product achieving its intended outcomes?" That change in the question requires a different team structure, a different funding model, a different measurement framework, and a different relationship between IT and the business.
Lululemon's transition under CIO Stacy Averill, who restructured the IT function to a product model during her tenure as EVP and Global CIO from 2017 to 2025, illustrates the change concretely. The transition moved IT workers away from delivering initiatives to teams that owned products and the outcomes they were meant to generate. The business, management, and the product teams were all aligned along a mission and an outcome. Centralized platform teams supported shared infrastructure and capabilities, becoming internal service teams that product teams could rely on rather than building infrastructure independently.
The structural elements of a product model that produce the outcomes the project model cannot are specific. A named product owner who is accountable for the product's business outcomes, not just its technical delivery. A stable, cross-functional team that includes both IT and business expertise, that does not disband after a release, and that develops the deep knowledge of the product's capabilities and limitations that enables rapid iteration. A continuous funding model that allocates investment to the product based on its strategic importance and performance, rather than through a project approval process that requires new funding requests for each change. And a measurement framework that tracks business outcomes, such as adoption rates, efficiency improvements, and customer satisfaction, rather than delivery metrics like on-time completion and budget adherence.
What the CIOs Who Have Made the Transition Know
The CIOs who have navigated the project-to-product transition report consistent insights about what makes it work and what makes it fail. CIO.com's analysis of multiple transitions, including the Lululemon case and cases at Hyatt and other organizations, surfaces three factors that distinguish transitions that produce the intended outcomes from those that produce reorganization without behavioral change.
The first is that the transition requires renegotiating the relationship with business leadership, not just reorganizing the IT function. A product team without genuine shared accountability between IT and the business, where the business leader is as accountable for the product's outcomes as the IT product owner, reproduces the vendor-client dynamic of the project model in a product team structure. The business leader who sees their role as specifying requirements and accepting delivery, rather than co-owning the product and its outcomes, has not shifted from the project model's accountability structure regardless of what the organizational chart says. The CIO who attempts the transition without securing this shared accountability model with business leadership will reorganize the IT function and find that the business continues to behave as a customer rather than a partner.
The second is that not all IT work belongs in a product model. Rob Holbrook, principal of technology strategy and architecture at Slalom, makes this point directly: some CIOs and their teams must cultivate a true product mindset where IT leaders and workers have a clear understanding of the product IT delivery model. The three-team structure that the product model requires distinguishes between product teams for customer-facing and business-aligned capabilities, platform teams for shared infrastructure and internal services, and operations teams for run-the-business activities that require consistency and reliability rather than continuous innovation. Applying the product model to all three categories produces the wrong team structure for two of them.
The Arthur D. Little April 2026 analysis describes the balance that the hybrid model achieves: product teams tailor solutions to specific business needs while building on standardized foundations, including shared platforms, security frameworks, architecture guidelines, and compliance controls. This combination accelerates decentralized innovation within a strategically orchestrated framework. The tech authority ensures adherence to enterprise governance while product teams experiment and iterate. Decisions on new features or investments are made collaboratively by product teams, technical leads, and the CIO. The result is a coherent ecosystem that supports rapid product-level development while maintaining consistent quality across the broader IT landscape.
The third is that the funding model change is as important as the organizational change. A product team that is funded through the project approval process, applying for a new budget each year for the work it plans to do, is a product team in structure and a project team in economics. Continuous funding models that allocate a defined investment to each product based on its strategic importance and its performance against outcome metrics, with the product owner responsible for allocating that investment across the product's roadmap, are the funding mechanism that gives product teams the autonomy and the accountability that the model requires.
Why the Question Keeps Being Deferred
The CIOs who know the project model is the problem and have not yet addressed it are not deferring because they lack information about what the alternative looks like. Most of them have read the same research, attended the same conferences, and heard the same arguments. The deferral is about the organizational negotiation required to implement the answer.
The project model gives business leaders a familiar form of control: they approve projects, they receive deliveries, they have a defined interface with IT that has been the same for decades. The product model asks them to share accountability for outcomes rather than exercise control over deliveries. That is a different ask. It requires business leaders to invest time in product governance that they currently spend on project approval, to accept that they are co-accountable for outcomes they cannot directly control, and to manage their relationship with IT as a partnership rather than as a procurement relationship. Not all business leaders are immediately willing to make that shift, and the CIO who attempts the transition without the CEO's active support for the business side of the accountability change will find the product model failing at the business-IT boundary.
The question becomes answerable when the CIO frames it not as an IT reorganization but as a business model for how technology investment generates business value. The technology strategy described in the technology strategy post in this series is the strategic context that makes the operating model question answerable: the strategy defines what outcomes technology investment is supposed to produce, and the operating model is the organizational design that produces those outcomes most efficiently. Framing the operating model question in those terms, rather than in terms of organizational structure and IT methodology, is what makes it a business conversation rather than an IT conversation, and a business conversation is one that business leadership can engage with as a partner rather than a recipient.
Talk to Us
ClarityArc helps CIOs work through the IT operating model question, assess which elements of the project model are producing the most significant organizational costs, design the product model structure and funding model that fits the organization's specific context, and build the case for the business leadership negotiation that makes the transition work. If you know the operating model needs to change and want a structured approach to making that change, we are ready to help.
Get in Touch