# Create a project

> Set up a project properly the first time — naming, dates, members and the settings that matter later.

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

Source: https://helpdesk.orangescrum.com/guide/cloud/projects/create-a-project

---
A project is the container for tasks, milestones, files, time and reporting.
Everything else hangs off it, so the few minutes spent here pay back.

## Create it

**Projects → Create**

    Or start from a [template](https://helpdesk.orangescrum.com/guide/cloud/projects/project-templates) if you
    have one that fits.

**Name and short name**

    The **short name** prefixes every task reference — `WR-142` — so keep it to
    two or three characters and make it unique. It appears in every standup,
    commit message and conversation, and changing it later invalidates
    references people have already written down.

**Type and status**

    Project type drives some reporting groupings. Status is Started, Hold,
    Stack or Completed.

**Dates**

    Start and end dates are optional but feed the
    [Gantt chart](https://helpdesk.orangescrum.com/guide/cloud/views/gantt-chart), calendar and portfolio views.
    A rough estimate beats leaving them blank.

**Members**

    Only members see the project. Add them now — an invited user with no project
    membership sees an empty workspace.

## Naming that scales

At five projects any naming works. At fifty it decides whether people can find
anything.

- **Do**: Name after the deliverable or client: "Acme — Website Redesign". Prefix consistently if you have client work.

- **Don't**: Name after time periods ("Q3 Work") or people ("Priya's Projects"). Both stop making sense within months.

## One project or several?

**One project per sprint?**

    No. Sprints live **inside** a project. A project per sprint scatters your
    history and breaks velocity tracking.

**One project per client?**

    Good if each client is one ongoing stream of work. If a client has several
    distinct deliverables with different teams, split them and group with
    [programs](https://helpdesk.orangescrum.com/guide/cloud/projects/programs) on Premium.

**One project per team?**

    Works when a team owns a continuous product. Use milestones for the
    delivery points.

**One giant project for everything?**

    Only at the very start. Filters stop being enough surprisingly quickly, and
    per-project reporting becomes meaningless.

> **Basic has a 10-project cap**
>
> If you create a project per client or release on Basic, count them before you
> design the structure. Pro and Premium are unlimited.

## Set up before you invite people

Two settings are much easier to get right before there is data:

- **Statuses**: On Pro and above, define your [custom statuses](https://helpdesk.orangescrum.com/guide/cloud/tasks/custom-fields-and-statuses) first. Renaming later leaves tasks in columns whose meaning has shifted.

- **Custom fields**: Add the two or three that genuinely drive decisions. Adding fields later is fine; back-filling them across 400 tasks is not.

## Members and visibility

Project membership controls visibility. Admins see everything regardless.

On Pro and above, manage membership through
[teams](https://helpdesk.orangescrum.com/guide/cloud/admin/teams-and-business-units) rather than individually —
far less churn when someone joins or moves.

> **Removing a member does not reassign their tasks**
>
> Their tasks stay assigned and disappear from the team's normal views.
> Reassign first.

## Archiving

Set status to **Completed** and filter it out. Keep the data — it feeds
historical reporting and estimates.

> **Deleting is permanent**
>
> Deleting a project removes its tasks, comments, attachments and logged time
> with no undo. Archive unless you are certain.

- [Next: project settings](https://helpdesk.orangescrum.com/guide/cloud/projects/project-settings): Everything you can configure once the project exists.