Projects: setup, delivery and lifecycle¶
A project brings a defined outcome, responsible people, delivery work and supporting evidence into one place. The portfolio helps you find projects and see their current state. A project record provides the starting point for execution, milestones, deliverables, repository evidence and reporting.
Availability: The backend implements project creation, portfolio and detail reads, setup changes and lifecycle actions. Four Final Screens define the intended starting journey. The current frontend uses sample project records, local action previews and sample reports; saving, live reads and deployment have not been verified. This draft covers setup, lifecycle, ordinary execution and formal governance. The execution guide explains sprint/phase organization, item changes, completion requirements and review. The governance guide adds promised outputs, milestone criteria, formal review requests and outcome limits. The repository evidence guide adds provider connections, imported activity, attribution, acceptance and removal limits. The dependencies and shared-delivery guide explains owner and participant attestations without implying that they complete work. The report guide explains current totals, charts, breakdowns and the limits of reconstructed history.
Read Create and manage a project for setup, lifecycle and recovery, then Plan, deliver and review project work for the intended execution journey and its current limits.
Choose the right delivery approach¶
| Approach | Meaning in this project model | First execution workspace |
|---|---|---|
| Agile | Organize delivery through backlog items and sprints. Creation adds an initial sprint. | Board |
| Plan-driven | Organize delivery through work packages and phases. Creation adds an initial phase. | Timeline |
Both approaches use the same project identity and lifecycle. Choose the primary approach before creating the project: the inspected setup update does not change it. The linked guides below explain execution, governance, evidence, dependencies, reporting and assistant interactions; connected delivery and remaining screen companions still require verification.
A newly created project is a Draft. Creating it does not activate delivery. Its initial sprint or phase takes the project's supplied dates; those dates do not establish that work has started or that later work automatically stays synchronized with setup changes.
Separate ownership from access¶
The signed-in creator becomes the saved project owner and an initial participant. Opening someone else's project does not transfer ownership. The inspected setup action cannot change that owner.
The owning organization unit, sponsor position and accountable delivery position provide organizational context. They identify a unit or position, which is different from naming the current project owner. The inspected backend permits these organizational fields to be absent. Agree appropriate accountability before starting work even where a field is technically optional.
Being an owner or participant does not by itself grant project-management access. Viewing and changing projects require the appropriate workspace permissions. Available lifecycle actions depend on both permission and the saved project state. A missing action may therefore be an access restriction, a state restriction or an unfinished frontend control.
Organization and person names are looked up for display. A missing name does not prove that a stored assignment was removed; a lookup may be unavailable. Ask an administrator to check an unresolved selection rather than substituting an unrelated person or unit.
Understand the project states¶
| Current state | Supported next actions, with management permission | Meaning |
|---|---|---|
| Draft | Activate or cancel | The initial record exists but has not entered active delivery. |
| Active | Put on hold, complete or cancel | The project is active. This status alone does not prove progress or approval. |
| On hold | Activate again, complete or cancel | The project-level status records a hold. Resuming clears its current hold reason. |
| Completed | No further lifecycle action in the inspected surface | The project has been closed as completed. |
| Cancelled | No further lifecycle action in the inspected surface | The project has been stopped and retains its cancellation context. |
Completed and cancelled projects cannot be reopened or setup-edited through this surface. An archived value exists internally, but an archive action is not provided here. Cancellation is a state change, not deletion or erasure.
Activation carries no note. Hold, completion and cancellation accept an optional note, respectively recorded as the hold reason, completion summary or cancellation reason. Keep notes concise; their stored limit is 512 characters. These fields are not an append-only discussion history.
Closure requires a delivery decision¶
The inspected project-completion action checks the project state. It does not require every execution item to be complete, every deliverable to be accepted, every milestone to be approved or every governance workflow to be resolved. A project marked Completed therefore does not, on its own, certify that those conditions were met.
Before completing or cancelling, the responsible manager should review outstanding work, evidence, acceptance and obligations, then record the decision and arrange any necessary follow-up. Treat putting a project on hold as a project status decision; this action does not itself pause all child work, linked workflows, deadlines or external systems.
Read portfolio figures in context¶
The intended portfolio combines a filtered project list with a summary for the same filter selection. Total projects, state counts and the number owned by you describe all matching records, rather than only the visible page. A project can contribute to both a state count and an ownership count, so those cards are not disjoint totals to add together.
Search currently matches project reference, title and description. Searching by a person's name is not supported by that search implementation, despite the inspected screen's broader hint. A separate owner filter exists in the backend, but its visible control has not been verified in this screen family.
These counts describe records and their state. They do not establish budget performance, delivery quality, staff productivity, contractual compliance or realized business value. Compare reports using the same filters and observation time. The list and summary are separate reads and can change between requests.
Responsibilities and remaining scope¶
Project owners maintain a useful title, reference, scope and dates. Managers agree the delivery approach, organizational responsibility and closeout decision. Executives use the portfolio as a starting point for discussion, then examine supporting work and evidence before drawing conclusions. Administrators maintain access and organization data; support teams investigate missing records or uncertain changes through authorized channels.
No project-specific price, quota or financial guarantee is established by this inspected path. Workspace availability and any wider commercial controls require their own verification. The general workspace permissions guide explains the surrounding access model.
The execution guide explains ordinary group/item changes, completion requirements and review. The deliverables, milestones and formal reviews guide adds ordinary acceptance, checkpoint criteria, approval requests and recovery. The repository evidence guide explains linking a source repository and assigning imported activity to project work, while distinguishing evidence acceptance from delivery approval. The dependencies and shared-delivery guide explains attestation rules, missing screen/readback limits and their distinction from delivery state. The report guide explains refresh, count meanings and reconstructed history without implying immutable snapshots or performance scores. The project assistant guide adds sourced questions, intended exact-change review and uncertain-result recovery. The contribution and data guide explains project outcome evidence, attribution limits and the workspace export/deletion boundary. The activity and people guide explains the intended governance summary, recorded events, reconstructed history and profile freshness. It also distinguishes timeline names from the identity needed for separate organization-history recording and identifies child work as a possible related item. Downstream analytics, shared activity operations and whole-platform lifecycle orchestration retain their own rules and verification. This draft does not claim that those parts of the system are fully explained or ready for audience acceptance.