Projects

A Project represents a timed endeavor with defined scope, timeline, and deliverables. Projects are the most feature-rich entities in PPM, supporting full lifecycle management with stages, tasks, and dependencies.

Every project has:

• Key — Unique identifier (2-20 uppercase alphanumeric characters, e.g., APOLLO)
• Name, Description, Business Case, Expected Benefits
• Status — Proposed, Approved, Active, Completed, or Canceled
• Date Range — Optional planned start and end date, set together
• Expenditure Category — Budget classification
• Lifecycle — Defines the stages the project goes through
• Roles — Sponsor, Owner, Manager, Member (see Project Roles)
• Health Check — Optional point-in-time project health signal (Healthy, At Risk, Unhealthy) with expiration
• Priority Score — Optional score recorded with the project's portfolio scoring model
• Portfolio Rank — Human-managed position within the project's portfolio, shown as Rank in project lists and available as a card-view sort mode
• Strategic Theme Tags — Links to strategic themes

Project Roles

Role	Description	May manage the project?
Sponsor	Executive sponsor of the project	No — sponsors fund and oversee, but don't run delivery
Owner	Person accountable for the project's outcomes	Yes
Manager	Responsible for planning and delivery	Yes
Member	Contributes to the project's work	No

Owners and Managers of the project's program or portfolio may also manage it — leadership inherits downward. See Permissions for the full rule.

Project Status Lifecycle

Projects move forward through these transitions, and can also be moved backwards — see Reverting a project status.

Business rules:

• A lifecycle must be assigned before a project can be approved
• Approval is optional: a Proposed project can be activated directly. The Actions menu offers Activate on a Proposed project once it has both a lifecycle and a date range, alongside Approve
• Active/Completed projects require a start and end date
• Only an active lifecycle can be assigned, and a completed or canceled project's lifecycle cannot be assigned or changed
• Only projects that have never left Proposed can be deleted — a project that ran and was later reverted keeps its history and cannot be deleted
• A project can belong to at most one program (or none)
• The project key can be changed (cascades to all task keys)
• A project is ranked within its portfolio from creation; rank is changed from the portfolio Ranking section

Reverting a Project Status

Projects get closed early, cancelled work gets refunded, and approvals sometimes turn out to be premature. Revert Status moves a project back to an earlier point in its lifecycle instead of leaving it stuck in a state that no longer reflects reality.

Choose Revert Status from the Actions menu, pick the status to return to, and give a reason. Where a project can go back to depends on where it is now, subject to the requirements below:

Current status	Can revert to
Completed	Proposed, Approved, Active
Canceled	Proposed, Approved, Active
Active	Proposed, Approved
Approved	Proposed
Proposed	— already at the start of its lifecycle

A status has the same entry requirements however it is reached. Reverting is not a way around the gates that apply going forward, so the same prerequisites hold:

• Returning to Approved requires a lifecycle to be assigned.
• Returning to Active requires a start and end date.

This matters most for cancelled projects. A project can be cancelled straight from Proposed, before it ever had a lifecycle or dates — such a project can only be reverted to Proposed until those are filled in. The dropdown only ever offers statuses the project actually qualifies for, so if a target you expect is missing, check the warnings at the top of the project page for what it still needs.

A reason is required. Forward transitions do not ask for one, because the move explains itself. Reverting undoes a decision that had already been taken and that other people may have acted on, so the explanation is kept in the project's status history alongside who did it and when.

A few more rules apply:

• Reverting is available to the same people who can move a project forward — an Owner or Manager of the project, its program, or its portfolio.
• A project inside a closed program or portfolio cannot be reverted. Closing a parent asserts that none of its children are still open, so reopen the parent first.
• Nothing else about the project is changed or cleared. Its dates, tasks, health checks, and scores are all preserved exactly as they were.

Programs and portfolios cannot be reverted — only projects.

Project Status History

Every status change is recorded, so a project's route through the lifecycle stays visible after the fact — when it was approved, how long it sat in Approved before activating, who moved it.

Open the history from the project detail page, either by clicking the status tag in the page header or by choosing Status History from the Actions menu. Both open the same timeline, newest change first. Each entry shows:

• The statuses moved from and to (the first entry has no "from" — it records the project entering its initial state)
• When the change happened
• Who made it
• The reason, on entries that carry one — reverting a project requires an explanation, so every backwards move records why

The history is append-only. Reverting a project adds a new entry showing the move back; it never edits or removes the transition it supersedes, so a project that was completed, reopened, and completed again shows all three.

Viewing history needs only view access to the project — you do not need to lead it.

Two things worth knowing about older projects:

• History for projects that predate this feature was reconstructed from the audit trail. It is accurate as to what changed and when, but a change made by someone whose account is no longer linked to an employee shows as Unknown.
• A project with no recorded status changes at all gets a single entry marking its current status, stamped at its creation date.

Project Detail Page

The project detail page has an identity bar naming the project, a section rail down the left, and a details panel holding the project's stable facts. Each section is addressable — the URL carries ?section= so a link can point at the section you were reading.

Record facts panel — Portfolio link, Program link (if assigned), date range, Expenditure Category, Lifecycle name with tooltip, Strategic Themes, Sponsors/Owners/Managers/Members, timeline progress bar, Priority Score (when enabled), and links. Toggle it from the button at the right of the identity bar; below tablet width it moves into the page content.

The identity bar also shows a Health tag when the project has an active health check. Hovering the tag shows details (status, reported by, reported on, expiration, and note). Clicking the status tag opens the project's status history.

Overview — Stages and, once tasks exist, a task summary.

The Stage Timeline is a step-based visualization showing each stage's status (completed, in progress, not started, canceled), date range, and progress percentage. It automatically adjusts between horizontal and vertical layout based on available space.

Warning alerts appear on Overview when requirements are missing:

• "Project Dates are required before activating"
• "A Project Lifecycle is required before approving"

Definition — Description, Business Case, and Expected Benefits, as expandable Markdown sections. Fields that have not been filled in read Not provided rather than being hidden, so a gap is visible on a project awaiting approval.

Team — Grid of the people working on the project: everyone who holds a project role, plus anyone assigned to an open task. Columns are Person, Roles, Assigned Stages, and Active Tasks — the Not Started and In Progress tasks assigned to that person, counting only tasks with no children.

Plan (only visible if lifecycle is assigned) — This is the project's work breakdown structure:

• Tree grid with hierarchical tasks organized by stage
• Drag-and-drop reordering (for users with update permission)
• Columns: WBS, Key, Name, Type, Status, Priority, Schedule, Planned Start, Planned End, Assignees, Progress, and Est Effort (hrs). For a milestone, Planned Start and Planned End both show its planned date
• Inline editing of Name, Type (Task/Milestone), Status, Priority, Planned Start, Planned End, Assignees, Progress, and Est Effort (hrs) on the selected row
• Schedule — derived from the dates and read-only: Overdue when the planned end has passed, Due This Week when it falls between today and Saturday, Upcoming when it falls in the following week. Completed and Canceled items carry no label
• Row actions: Edit task, Delete task, Add child task; on a stage row, Edit (the stage's description, status, assignees, planned date range, and progress) and Add Task
• Task details drawer: Click a task Key to open a side drawer with task/milestone details
• Drawer actions: Edit, Delete, and Add child task (same actions as row menu)
• Drawer links: Parent Task and Assignees are clickable links
• Description rendering: Task Description supports Markdown
• Filtering by task type, status, and priority (Type filter includes Stage)
• Keyboard shortcuts for efficient navigation

Common keyboard shortcuts in Plan:

• Enter or Down Arrow: Save and move to next row
• Up Arrow: Save and move to previous row
• Tab / Shift+Tab: Move between editable fields
• Esc: Cancel current edit or drag operation

Work Items — Grid of work items from Work Management that are associated with this project.

Activity — The project's recorded history: what changed, who changed it, and when. See Activity Log.

Health Report — A report rather than a section, so it sits below the divider at the bottom of the rail. See View the Health Report.

Forecast — A second report, shown when the delivery-forecasting feature flag is on: when the project's work items will be done, and the chance of finishing by the project's planned end. See Delivery Forecasting.

Project Actions Menu

The page-level Actions menu changes based on project status, your permissions, and whether you lead the project.

Typical actions include:

• Edit
• Change Program
• Change Key
• Assign Lifecycle (when no lifecycle is assigned)
• Change Lifecycle (when a lifecycle is already assigned)
• Delete (available for Proposed projects)
• Status transitions such as Approve, Activate, Complete, and Cancel
• Revert Status (when the project has an earlier status it can return to — see Reverting a project status)
• Status History

Create Health Check sits beside the menu as its own button, since recording health is the recurring action on a live project. It carries the same permission rule as the menu actions below. The Health Report is reached from the rail — see View the Health Report.

Who can perform these actions

Every action above except Delete and Status History — and the Create Health Check button — requires both the Permissions.Projects.Update permission and delivery leadership on the project — you must be an Owner or Manager of the project, its program, or its portfolio. Sponsors and Members are not sufficient.

Delete requires Permissions.Projects.Delete. Status History and the Health Report require only view access.

If an action is missing from the menu, see why an action might be unavailable.

Project Priority Scores

Project priority scores help portfolio and project leaders compare projects using a consistent, formula-driven model such as WSJF. Scoring is enabled at the portfolio level by assigning an active scoring model.

When scoring is enabled, the project details page shows a Priority Score panel. The panel shows the latest score, the scoring model name, who scored it, when it was scored, and a View history link when score history exists.

The portfolio Ranking section can also show the current scoring model's criterion and output columns for every ranked project. The primary output appears as the score badge. A blank score breakdown means the project is unscored or its current score was recorded with a different scoring model.

Record or Update a Score

1. Open the project detail page.
2. In the Priority Score panel, click Score or Re-score.
3. Rate every criterion. Criteria with scales use dropdown levels; criteria without scales accept numeric input.
4. Optionally click Preview to calculate every output value before saving.
5. Click Save score.

Each saved score is a new history entry. Re-scoring does not overwrite the previous score; it updates the project's current score summary and keeps the earlier score available in history.

Score History

Use View history in the Priority Score panel to review previous scores. Each score records:

• The scoring model name and primary score value
• The person who recorded the score and when it was recorded
• The selected criterion ratings
• Every calculated output value, with the primary output marked as the score

Scores are immutable snapshots. If the portfolio changes scoring models later, existing scores still show the model, ratings, and outputs used at the time they were recorded.

Permissions

Users need project update rights and management access to record scores. Project Owner/Manager, portfolio Owner/Manager, or program Owner/Manager access is sufficient — this is the same delivery-leadership rule that governs every other project change. Users with project view access can view current scores and score history.

Project Health Checks

Project health checks let teams record a current health signal for a project and track it over time.

Create a Health Check

1. Open a project detail page.
2. Click Create Health Check, beside the Actions menu.
3. Select a status: Healthy, At Risk, or Unhealthy.
4. Optionally add a Markdown note.
5. Set an expiration (must be a future date/time), then click Create.

After creation, the current health appears as a flag/tag in project views. A project has one current health check at a time: creating a new one ends the current one, setting its expiration to the moment the new one was recorded. Once a check expires the project has no current health until the next one is created.

View the Health Report

From the project detail page, select Health Report in the section rail, under Reports.

The Health Report includes:

• Health Status History Chart — Timeline distribution of health checks by status
• Health Checks Grid — Status, Note, Reported By, Reported On, Expiration

Use this view to review trends and reporting history for the project.

Where Health Appears

• Projects list/grid includes a Health column.
• Project detail header shows the current health flag/tag.
• Projects Dashboard shows health on every project and counts Unhealthy, At Risk, and unreported projects in its attention tiles.

Permissions

To create, edit, or delete project health checks, users need project update rights and management access on the project context (for example, project owner/manager or equivalent portfolio/program management access) — the same delivery-leadership rule that governs every other project change. Users with project view access can still view health checks and health reports.

Project Lifecycles

A Project Lifecycle defines the template of stages that a project goes through from inception to completion. Lifecycles are configured in Settings > PPM > Project Lifecycles.

Lifecycles have a state:

• Proposed — Being defined; stages can be added, modified, reordered
• Active — In use; stages are locked and cannot be changed
• Archived — No longer assignable to new projects (existing projects unaffected)

Each lifecycle contains ordered Stages (e.g., Initiation, Planning, Execution, Closing). When a lifecycle is assigned to a project, its stages are copied as Project Stages that can then be tracked independently.

Business rules:

• Must have at least one stage before activation
• Only Proposed lifecycles can have stages modified
• Only Proposed lifecycles can be deleted

Projects can change lifecycles after assignment. When changing, a mapping dialog allows you to map tasks from the project's existing stages onto the new lifecycle's stages.

Project Stages

When a lifecycle is assigned to a project, its template stages become Project Stages — concrete instances that track actual progress.

Each stage has:

• Name — Copied from the lifecycle template (not editable)
• Description — Editable per project
• Status — Not Started, In Progress, Completed, or Canceled
• Date Range — Planned start and end dates
• Progress — 0-100% completion
• Roles — People assigned to work on this stage (Assignee)

Project Tasks

Tasks are the actionable work items within a project stage. They support a hierarchical work breakdown structure (WBS).

Task Types

• Task — A work item with a date range and partial progress (0-100%)
• Milestone — A point-in-time marker with a single target date; can only be Not Started or Completed (no In Progress)

Task Properties

• Key — Auto-generated as \{ProjectKey\}-\{Number\} (e.g., APOLLO-42)
• Name and optional Description
• Type — Task or Milestone
• Status — Not Started, In Progress, Completed, or Canceled
• Priority — Low, Medium, High, or Critical (shown as color indicators)
• Progress — 0-100% for tasks; 0 or 100 for milestones
• Order — Position within parent for WBS structure
• Date Range — Planned start and end dates (tasks) or Planned Date (milestones)
• Estimated Effort — Hours estimate
• Roles — Assignees
• Dependencies — Finish-to-Start relationships between tasks

Task Hierarchy

Tasks can contain child tasks, creating a work breakdown structure:

Business rules:

• Milestones cannot have child tasks
• Milestones cannot be In Progress (only Not Started or Completed)
• Tasks cannot be deleted if they have children or active dependencies
• Tasks cannot be moved under their own descendants (prevents circular references)
• Date Rollup — Stage and parent task date ranges automatically roll up from child dates:
  • If a stage or parent task has dated children, its range automatically expands to cover the minimum start date through the maximum end date of its descendants.
  • A stage or parent task date range cannot be manually shrunk behind its children's dates, nor can its dates be cleared while any of its descendants have dates.
  • Leaf regular tasks and empty containers can remain undated.
  • Shifting a parent task's range offsets all of its dated descendants by the same duration.

Gantt Chart

The Plan section pairs the task grid with a Gantt chart on the right, sharing the same rows: each grid row draws its schedule on a common date axis. The chart is shown by default and can be hidden from the toolbar.

Row	Drawn as
Stage	A summary bar spanning its tasks. A stage with no dates of its own is rolled up from its children
Task	A bar from planned start to planned end, shaded to show progress
Milestone	A diamond on its planned date

Rows with no dates draw nothing — the grid still lists them, so an unscheduled plan is visible rather than hidden.

Toolbar controls:

Control	Action
Chart button	Show or hide the chart pane
+ / − buttons	Zoom in / out
Reset zoom button	Return to the default zoom
Ctrl/Cmd + scroll	Zoom in / out over the chart
Drag the divider	Resize the chart pane

Showing or hiding the chart is remembered on your device and applies to every project plan, not just the one you toggled it on. Roadmap charts keep a separate preference of their own.

Rescheduling (requires permission to manage tasks):

Control	Action
Drag a bar	Move the task, keeping its duration
Drag a bar's left/right handle	Change the planned start or end date
Drag a diamond	Change a milestone's planned date
Esc during drag	Cancel without saving

Dragging saves the new dates immediately and follows the same rules as editing dates in the grid — including date rollup, so moving a task past the edge of its stage expands the stage to contain it.

Task Dependencies

Tasks support Finish-to-Start dependencies — a predecessor task that should finish before its successor starts. Dependencies are soft-deleted (marked as removed rather than permanently deleted).

Dependencies are added and removed through the API and the MCP server; the Plan section does not show or edit them. Wayd records the relationship but does not enforce it: a successor's status and dates can change whatever its predecessor's state.

• A task cannot depend on itself, and both tasks must belong to the same project.
• A predecessor can have only one active dependency on the same successor.
• Chains are not checked for cycles.
• A task with an active dependency in either direction cannot be deleted until the dependency is removed.

Note: These are project task dependencies within PPM. For work item dependencies across workspaces, see Work Item Dependencies.

Common Tasks

Creating a Project

1. Navigate to PPM > Projects
2. Click Create Project
3. Choose an Active or On Hold Portfolio, and optionally an active Program in it
4. Enter Key (project code), Name, Description, and Expenditure Category
5. Optionally set Business Case, Expected Benefits, Planned Date Range, the Sponsors, Owners, Project Managers, and Members, and Strategic Themes
6. Optionally choose a Lifecycle — the form previews its stages. A lifecycle can also be assigned later with Assign Lifecycle
7. Approve the project (requires lifecycle), then Activate (requires date range)

Managing Project Stages and Tasks

1. Navigate to the project detail page
2. Go to the Plan section (visible once a lifecycle is assigned)
3. Create tasks within each stage — choose Task or Milestone type
4. Set priority, dates, assignees, and estimated effort
5. Drag and drop to reorder tasks within stages
6. Use the Gantt chart to review the schedule and drag bars to reschedule
7. Track progress and update statuses

Reporting Project Health

1. Open the project detail page.
2. Use the Create Health Check button to record current health.
3. Add a concise note explaining risk, impact, and next step.
4. Set an expiration aligned to your next review cadence (for example, 1-2 weeks).
5. Review the Health Report, under Reports in the section rail, during project reviews to track trend changes.

Setting Up a Project Lifecycle

1. Navigate to Settings > PPM > Project Lifecycles
2. Click Create Lifecycle
3. Add Stages in order (e.g., Initiation, Planning, Execution, Closing)
4. Activate the lifecycle when the stage list is complete
5. The lifecycle can now be assigned to projects