# Projects

> Plan projects as tasks with durations and dependencies, see when they will finish, and follow the GitHub work that delivers them.

Plan the work, and Projects tells you when each project will finish and whether it makes its due
date.
Projects is early: it covers planning and scheduling, and more is coming.

## How work moves

You plan a project, Continual schedules it, and the people who own its tasks move them to done.

1. A **project** names an outcome, an owner, and a due date, such as "Open the Denver office".
2. Its **tasks** are the work, each with an owner and a duration in working days.
3. A **dependency** says what a task waits for, such as another task's finish.
4. Continual times every task from those, and forecasts when the project finishes.

When you connect GitHub, your **repositories**, **pull requests**, and **issues** sync in beside your
projects, so you can follow the code work that delivers them.

## What Continual does here

Continual schedules every project with the critical path method, working Monday to Friday from
today. It writes each task's scheduled dates and slack, marks the tasks with no slack **Critical**,
and sets each project's **Forecast finish**. It marks a project **Late** when its tasks cannot
finish by its due date.

It schedules again when a task or dependency changes, and each day, since tasks not yet started
move with today. It also marks each unfinished task **Ready** or **Blocked**. See
[Tasks](/docs/apps/projects/tasks) for how.

## Metrics

Projects adds four [metrics](/docs/concepts/metrics) under **Metrics**: **Open tasks**, **Tasks
done**, **Cycle time**, and **Age of open tasks**. Each is a sum of what your tasks record as their
status changes, so you can open the tasks behind any number.

<TryAsking
  prompts={[
    "Which projects will miss their due date?",
    "What is on the critical path for SOC 2 Type II readiness?",
    "Add a 3-day task to SOC 2 Type II readiness to write the incident response policy, after the tabletop exercise.",
  ]}
/>

## Who can do what

Everyone in your organization can start a project. Whoever starts one owns it, and only they see it
until they share it, with people or with everyone. An **Editor** can change the project, its tasks,
and their dependencies; a **Viewer** reads them. Everyone who
works in Projects can read the synced GitHub records.

## Records

Projects keeps six kinds of record. Each page explains how the record works and lists its fields.

<Cards>
  <Card title="Projects" href="/docs/apps/projects/projects" icon="folder">
    Work with an outcome, an owner, and a due date.
  </Card>
  <Card title="Tasks" href="/docs/apps/projects/tasks" icon="check">
    Work in a project, scheduled on the critical path.
  </Card>
  <Card
    title="Dependencies"
    href="/docs/apps/projects/dependencies"
    icon="list"
  >
    What a task waits for.
  </Card>
  <Card
    title="GitHub repositories"
    href="/docs/apps/projects/github-repositories"
    icon="code"
  >
    Synced repositories, and how the sync runs.
  </Card>
  <Card
    title="GitHub pull requests"
    href="/docs/apps/projects/github-pull-requests"
    icon="code"
  >
    Synced code changes and the issues they address.
  </Card>
  <Card
    title="GitHub issues"
    href="/docs/apps/projects/github-issues"
    icon="code"
  >
    Synced issues from your repositories.
  </Card>
</Cards>

## Next steps

<Cards>
  <Card
    title="Plan and run a project"
    href="/docs/guides/run-a-project"
    icon="folder"
  >
    Create a project, add its tasks, and read the schedule.
  </Card>
  <Card title="To-dos" href="/docs/concepts/to-dos" icon="check">
    How a task becomes a to-do when it needs someone.
  </Card>
  <Card title="Inbox" href="/docs/apps/inbox" icon="inbox">
    Bring email into the record.
  </Card>
</Cards>