The Death of the IT Project: Why Everything Is Becoming a Product (and Why Most Enterprises Still Get It Wrong)
Saumitra Kalikar

For decades, the IT project has been the primary vehicle through which enterprises have delivered change, providing structure and predictability in a world that was relatively stable. That context has fundamentally shifted. Today’s enterprises operate in conditions of continuous disruption, where customer expectations evolve rapidly, competitive boundaries blur, and technology is inseparable from business value creation. In such an environment, the notion that value can be delivered through finite, time-bound initiatives is increasingly misaligned with reality.
This is why organisations are declaring the “death of the IT project” and embracing the language of products, reframing technology capabilities as enduring assets, reorganising teams around value streams, and rethinking funding to support continuous evolution. However, most enterprises are not truly transitioning to a product operating model; they are layering product terminology onto project-based structures, inheriting the complexity of both models without fully realising the benefits of either.
The project isn’t dead in most enterprises—it has simply been renamed.
The persistence of project thinking in a “product” world
Despite widespread adoption of product language, the underlying mechanics of most organisations remain anchored in project-era constructs such as annual budgeting cycles, scope-based funding, and milestone-driven success measures. What has changed is largely the narrative, not the operating model, creating a disconnect between intent and execution.
This creates a structural contradiction where product models, designed for adaptability and learning, are forced into rigid funding and governance frameworks. Teams are evaluated on short-term delivery while being asked to deliver long-term outcomes, resulting in ambiguity, slower decision-making, and diluted accountability.
You cannot operate like a product organisation while funding and governing like a project organisation.
The ownership illusion: product vs enterprise governance
A defining characteristic of a true product model is end-to-end ownership, where product leaders are accountable not only for delivery but for sustained business outcomes. In practice, this ownership is often fragmented, as enterprise functions such as architecture, security, risk, finance, and operations retain decision rights within their respective domains.
This creates an ownership illusion in which accountability is decentralised but control remains distributed across governance silos. Decisions become fragmented, trade-offs are escalated, and agility is constrained by approval-heavy processes, requiring a fundamental redesign of how governance operates.
If teams are accountable for outcomes but don’t control the decisions, ownership is only theoretical.
Funding models: the CapEx trap
Traditional funding models are built on a CapEx mindset, where investments are approved for defined scopes with clear start and end points. This model is fundamentally misaligned with product thinking, where value is realised incrementally and products evolve continuously.
A true product operating model requires a shift to persistent, outcome-based funding aligned to value streams rather than projects. Finance must evolve into a dynamic capital allocator, continuously adjusting investment based on performance and learning rather than static business cases.
Continuous products cannot be sustained on episodic funding.
Measuring value beyond delivery milestones
Project success has traditionally been measured by adherence to scope, timeline, and budget, offering control but limited insight into actual value creation. In a product model, the focus shifts to sustained business impact, requiring metrics such as customer adoption, efficiency gains, revenue contribution, and risk reduction.
Many organisations struggle to operationalise these metrics due to gaps in data, governance, and cultural alignment. In the absence of this capability, they revert to milestone-based tracking, reinforcing project-era behaviours and undermining the product model.
If you measure delivery, you optimise for activity—if you measure outcomes, you optimise for value.
The case for true end-to-end ownership
A successful product operating model is built on true end-to-end ownership, where a single team is accountable for the entire lifecycle of a product, from ideation to optimisation. This ownership must span both technology and business to ensure alignment between delivery and value creation.
In many organisations, product teams remain IT-centric while business stakeholders operate externally, creating a disconnect that weakens accountability. True product organisations integrate business, technology, data, and operations into unified, outcome-driven teams.
Products don’t create value—fully accountable teams do.
What a real product operating model looks like
A genuine product operating model is defined by how funding, governance, accountability, and delivery are structurally aligned to enable continuous value creation. At its core lies structured autonomy, where product teams operate with real decision-making authority within clearly defined enterprise guardrails.

Persistent, outcome-based funding
Investment shifts from projects to value streams, with finance continuously reallocating capital based on performance, strategic alignment, and learning rather than upfront scope.
Clear product ownership
Product leaders are accountable for end-to-end outcomes, spanning strategy, delivery, adoption, and optimisation, with real authority exercised within enterprise-defined constraints.
Enterprise functions as enablers, not gatekeepers
Architecture, security, risk, and compliance define principles, standards, and non-negotiable controls, shaping decisions through system design rather than approvals.
Guardrails operationalised through platforms
Enterprise standards are embedded into platforms such as DevSecOps pipelines, reusable services, and automated controls, enabling speed with built-in compliance.
Continuous, data-driven governance
Governance shifts from stage-gate approvals to real-time monitoring, automated policy enforcement, and exception-based escalation, enabling live assurance.
Cross-functional, long-lived teams
Teams integrate business, technology, and operations capabilities, ensuring products are built, run, and evolved as a single lifecycle.
Outcome-driven measurement
Success is measured through sustained business impact, with metrics directly informing funding decisions, governance oversight, and strategic direction.
A practical illustration can be seen in organisations like Amazon, where autonomous teams own products end-to-end while operating within a highly engineered ecosystem of shared platforms, embedded controls, and continuous governance. This combination of decentralised execution and centralised coherence enables scale without fragmentation and speed without loss of control.
Agility at scale is achieved not by removing control, but by redesigning how control is embedded into the system.
Why most enterprises will get it wrong
The transition from projects to products is often underestimated because it is treated as a delivery transformation rather than an operating model transformation. Organisations introduce product roles and agile practices while leaving funding, governance, and measurement systems unchanged.
This creates systemic friction, where product teams are expected to operate with autonomy but remain constrained by legacy controls. Over time, this misalignment erodes confidence, and organisations revert to project-based approaches under new terminology.
The failure is not in adopting the product model—it is in trying to adopt it without changing the system around it.
Where to start
A full-scale transformation is rarely practical as a starting point. A more effective approach is to focus on a small number of high-impact value streams where true product principles can be implemented end-to-end.
These areas serve as learning environments where both product teams and enterprise functions evolve together. The objective is progressive capability building, not immediate perfection.
You don’t transform the enterprise in one move—you prove the model, then scale it.
A final reflection for leadership teams
The death of the IT project is not about abandoning discipline or governance, but about recognising that value in a dynamic environment cannot be delivered through finite initiatives alone. The real challenge is redesigning the enterprise mechanisms that underpin how technology is funded, governed, and measured.
Product teams can only be truly accountable if enterprise functions evolve into system designers, governance is embedded into the flow of work, and funding aligns with outcomes. Without these shifts, the product model remains rhetoric; with them, it becomes a powerful mechanism for aligning technology and business strategy at scale.
