Why Projects are a Waste

When organisations want to change, improve or innovate, the default response is almost always the same: they start a project.

A new system? A project. Process improvement? A project. A digital initiative? A project.

Over time, projects have become the standard mechanism for dealing with change. They are so familiar that they are rarely questioned. Yet it is worth pausing to ask a simple but uncomfortable question:

Is a project always the right response or merely the most familiar one?

Why projects feel like the safe choice

Projects are attractive for understandable reasons. They provide structure in situations where outcomes are uncertain. They come with a defined scope, a clear start and end date, a budget, and an explicit governance model. Accountability appears clear, progress can be reported, and risk feels contained.

In many organisations, projects fit neatly into existing financial, governance and management structures. Budgets are approved per initiative, steering committees are formed, milestones are tracked, and success is measured by delivery.

In that sense, projects offer something valuable: a sense of control. And in complex environments, control is reassuring.

The hidden trade-off of project thinking

However, what projects provide in control, they often take away elsewhere.

By design, projects are temporary. Responsibility is assigned for a limited period of time, after which ownership is handed back to “the organisation”. In practice, this often means that subject-matter experts are pulled from long-lived teams to contribute to temporary initiatives, while accountability for outcomes remains fragmented.

Knowledge is spread thin. Context is lost. Teams are asked to support change without truly owning it. Projects optimise for delivering predefined scope. Value creation, however, is continuous.

This difference matters. Improvements introduced through projects often slow down or disappear once the project ends, precisely because the teams responsible for running the system were never truly accountable for its evolution.

Can a project ever be Agile?

Many organisations attempt to address these issues by running projects “the Agile way”. Scrum ceremonies are introduced, backlogs are created, and teams work in iterations.

While this may improve transparency and collaboration, it does not fundamentally change the nature of the construct.

A project can use Agile practices, but structurally it remains a temporary arrangement. Scope is still defined upfront, success is still measured by delivery, and ownership still sits outside the team once the project concludes.

Agile thinking assumes continuous ownership. Project thinking assumes temporary responsibility. Those two assumptions do not sit comfortably together.

Investing in teams instead of initiatives

An alternative approach starts from a different premise: value is created by teams over time, not by initiatives with an end date.

In this model, teams are treated as long-lived units with clear product or domain ownership. Improvement is not a separate initiative but part of their ongoing responsibility. Priorities are continuously reassessed, trade-offs are made close to the work, and learning accumulates rather than resets.

This does not mean unlimited autonomy or a lack of discipline. It means shifting the focus from funding change to funding capability.

Instead of asking “what projects do we need?”, organisations ask: “Which teams do we invest in to deliver and evolve our core value?”

What changes when organisations invest in teams

When teams are given long-term ownership, several things change.

Knowledge stays where it belongs. Decisions are informed by context rather than documentation. Feedback loops shorten. Accountability becomes clearer, not weaker, because the same teams are responsible for both delivery and outcomes.

Importantly, improvement no longer competes with delivery — it is delivery.

This shift also changes the role of leadership. Instead of coordinating projects, leaders focus on setting direction, clarifying priorities and creating the conditions under which teams can make good decisions.

Governance without projects: the real concern

At this point, many organisations hesitate. If we reduce our reliance on projects, how do we maintain governance, control and risk management?

This concern is legitimate. But it rests on a false assumption: that governance requires projects. In reality, governance does not disappear when projects disappear — it simply changes form.

Instead of steering committees and milestone reports, governance becomes focused on outcomes, decision rights and boundaries. Instead of approving detailed plans, leadership defines clear objectives, constraints and escalation paths. Transparency replaces reporting. Trust is balanced with accountability.

This form of governance is often more demanding, not less. It requires clarity about who decides what, where responsibility truly sits, and how success is measured.

Making the choice explicit

The real issue, then, is not whether projects are good or bad. The issue is that organisations rarely make an explicit choice between funding projects and investing in teams.

Some work is genuinely project-shaped: one-off changes with a clear end state. But much of what organisations treat as projects is actually ongoing product development, capability building or continuous improvement.

When everything becomes a project, nothing is truly owned. Real progress starts when organisations stop asking teams to deliver projects, and start enabling them to continuously create value.