When Should You Set Up a Programme Instead of Running Standalone Projects?

## The short answer

Set up a programme when several projects must be **coordinated to deliver a shared outcome** that none can achieve alone — typically when they have significant interdependencies, compete for the same resources, or all serve one strategic objective that needs central benefits management. If your initiatives are genuinely independent, *don't* form a programme; the coordination overhead will cost you more than it saves. The decision is about the shape of the work, not its size.

## Programmes are not just "big projects"

The instinct to create a programme often comes from scale: this is large and important, so it must need a programme. But size alone is the wrong trigger. A single large, well-bounded project with one team and a stable scope is best run as a project, however big the budget. Conversely, three small but tightly interdependent projects serving one outcome may genuinely need programme coordination despite modest individual size.

The right question is not "how big is this?" but "do these pieces of work need to be coordinated to deliver value, and would they fail if managed independently?"

## The tests that point to a programme

Form a programme when several of these are true:

1. **Shared outcome** — multiple projects only deliver value collectively; individually they're incomplete.

2. **Heavy interdependencies** — projects rely on each other's outputs, and uncoordinated sequencing would cause failure.

3. **Contested resources** — the same scarce people, environments or budget are needed across projects and must be allocated centrally.

4. **Benefits that span projects** — no single project owns the benefit, so someone must manage realisation across all of them.

5. **Coherent change** — the projects together impose change on the business that must be sequenced so operations can absorb it.

6. **Strategic alignment** — leadership needs a single point of accountability for whether the whole thing delivers on strategy.

The more of these you tick, the stronger the case for a programme.

## The tests that point *away* from a programme

Resist forming a programme when:

- The initiatives are genuinely independent and could each succeed or fail without affecting the others.

- There are no meaningful shared dependencies or resources.

- Each project has its own clear, self-contained benefit and owner.

- The work is really one cohesive piece best run as a single project.

In these cases a programme adds boards, reporting layers and coordination ceremony that buy you nothing. Worse, it can blur accountability that was perfectly clear at project level. Over-structuring is as real a failure as under-structuring.

## Beware the accidental programme

The most common real-world situation is neither a clean project nor a deliberate programme — it's a project that has *grown into* a programme without anyone noticing. It started as one initiative, sprouted sub-projects, acquired cross-team dependencies and a web of stakeholders, but is still governed with a single plan and a weekly status call.

This is the worst of both worlds: programme-shaped complexity managed with project-shaped tools. Nobody owns the overall outcome, dependencies fall through the cracks, and benefits go untracked. If you recognise your initiative in this description, that's a strong signal to formalise it as a programme — appoint a sponsor, build a dependency map, and put benefits management in place.

## What forming a programme actually commits you to

Deciding to run a programme is not free. You're committing to:

- A senior sponsor accountable for benefits.

- Programme-level governance and decision rights.

- Central management of dependencies, resources and risk.

- Benefits management across the whole portfolio of work.

- Coordination overhead that takes time and people.

That investment is worth it when coordination genuinely creates value. It's pure cost when the work didn't need coordinating in the first place. Make the decision deliberately, with eyes open to both the benefit and the price.

## A simple decision rule

If the initiatives **must be coordinated to succeed**, run a programme. If they **merely happen at the same time**, run them as separate projects and, if you need oversight, use lightweight portfolio reporting rather than full programme machinery. "Happening together" is not the same as "belonging together".

At neart.ai we build enterprise-grade delivery and PMO tooling, and we see both failure modes regularly: real programmes run as loose collections of projects, and simple projects buried under needless programme governance. Matching the structure to the actual shape of the work is one of the highest-leverage decisions a delivery leader makes.

## Practical takeaway

Don't decide by size — decide by coordination. Form a programme when projects share an outcome, depend on each other, or compete for the same resources and benefits. Keep things as standalone projects when they're genuinely independent. And if you spot an accidental programme — project-shaped governance straining under programme-shaped complexity — formalise it before the seams give way.