# Programs

> Group related projects into a program and manage them as one initiative.

> For the complete documentation index, see [llms.txt](https://helpdesk.orangescrum.com/llms.txt).

Source: https://helpdesk.orangescrum.com/guide/cloud/projects/programs

---
> **Premium Unlimited**
>
> Program management is a Premium feature. See
> [Plans and limits](https://helpdesk.orangescrum.com/guide/cloud/plans/plans-and-limits).

A **program** groups related projects that together deliver one outcome — a
product line, a client account, a multi-workstream transformation. It gives you
a level above the project without forcing everything into one enormous project.

## When you need one

- **You do need a program**: Several teams, separate projects, one shared outcome and one sponsor asking "how is it going?" across all of them.

- **You don't**: A single team with several workstreams. Use milestones inside one project.

Signals it is time:

- You are manually assembling a status report from three project views
- The same dependency keeps crossing project boundaries
- One person is accountable for delivery across several projects
- Budget is tracked at a level above the individual project

## Setting one up

**Create the program**

    Name it after the outcome, not the department. "Mobile launch" ages better
    than "Digital team work".

**Add projects**

    Existing projects can join without disruption — their tasks, history and
    reporting are untouched.

**Assign an owner**

    One accountable person. A program with no owner becomes a folder.

**Set dates and budget**

    Program-level dates and budget roll up from and against the member projects.

## What it gives you

| View | Answers |
| --- | --- |
| **Program overview** | Where does the whole initiative stand? |
| **Rolled-up timeline** | How do the project timelines interact? |
| **Cross-project dependencies** | What is blocking what, across teams? |
| **Aggregate budget** | Total spend against total budget |
| **Resource view** | Who is committed across the program? |

## Structure that works

**Keep projects meaningful on their own**

    Each project should still make sense to the team that runs it. A program is
    a lens over projects, not a reason to fragment work into pieces too small to
    manage.

**Make cross-project dependencies explicit**

    The dependencies that hurt are the ones between teams. Record them —
    otherwise they surface as a surprise in the week they bite.

**Don't nest programs**

    A program of programs is an org chart, not a plan. If you need that, the
    scope is probably too broad.

**Close programs when they finish**

    An initiative that "ends" but stays open drifts into being a permanent
    department view, and stops meaning anything.

## Reporting

Programs feed the [advanced dashboards](https://helpdesk.orangescrum.com/guide/cloud/agile/reports) — progress,
budget consumption and resource load across every member project. This is the
view for a steering meeting, where per-project detail is too granular.

> **Roll-ups inherit their inputs' quality**
>
> Program reporting is only as good as the underlying projects. If one team does
> not maintain dates or statuses, the program view is confidently wrong. Fix the
> project hygiene first.

- [Resource management](https://helpdesk.orangescrum.com/guide/cloud/time/resource-management): Who is committed where, across the program.

- [Budget and cost](https://helpdesk.orangescrum.com/guide/cloud/time/budget-and-cost): Tracking spend at program level.