The Project at the Center

In GreenVee, the Project is the central organizing unit. It is not just one screen among many — it is the entity that everything else attaches to. When a piece of data does not seem to belong anywhere obvious, the answer is almost always: it belongs to a project.

Key fields on a project

Field	What it means
Title	The human-readable name for the project.
Customer	The company or person the project is being delivered for.
Project Type	A master-data classification (e.g. “PV installation”, “switchgear”) that groups similar projects and controls which workflows apply.
Phase	Where the project is in its lifecycle: Initial, Definition, Planning, Execution, Closing, Successfully Closed, or Cancelled. See Project Lifecycle.
Planned start / Planned end	The intended schedule as agreed at the start.
Actual start / Actual end	When work actually began and finished. These fill in as the project progresses.
Address	The physical location where the installation or work takes place — important for field logistics.
Budget goal	The target spend. Actual costs tracked in the budget spine are compared against this figure.
Currency	All monetary values on the project are expressed in this currency.
Tags	Free-form labels used for filtering and grouping projects in portfolio views.

Note

The phase field is set by users — GreenVee does not move a project between phases automatically. Gates can signal readiness to advance, but a human still makes the call. See Project Lifecycle.

Where a project sits in the hierarchy

A project always belongs to exactly one Portfolio. This relationship is required — there is no free-floating project outside a portfolio. Optionally, a project may also belong to a Program, which is a grouping inside a portfolio for related projects that share resources or a delivery goal.

Portfolio
  └── Program (optional grouping)
        └── Project ← you are here

On the commercial side, a project may be linked to exactly one Order — the sales record that captures what the customer contracted for. This is a 1:1 relationship; a project does not span multiple orders, and an order does not span multiple projects.

What hangs off a project

Once a project exists, it becomes the anchor for a large ring of related data:

Spine	Category	What is attached
A	Work plan	Segments, task packages, tasks, subtasks, milestones, gates
B	Technical structure (Plant)	Nodes, required goods, specifications
C	People and Time	Project Members (employees + their role and rate on this project); planned hours, bookings, time entries
D	Money	Budget, cost items, cost occurrences, procurement orders
E	Materials	Usage of goods and variants tracked against tasks
—	Risks & Chances	Project Risks and Chances, each with their own actions; Portfolio Risk Factor scores
—	Documents	Files, meeting minutes, status reports, decision logs
—	Contacts	Customer and supplier contacts linked to this project

For a full breakdown of the five spines, see The Five Spines.

For Project Managers

Your daily work lives in the work plan and team sections. The project’s key fields — especially phase, planned dates, and budget goal — are the anchor for every status conversation you will have.

For Finance

The budget goal and currency set here are the top-level targets that the budget spine (cost items, occurrences, orders) fills in beneath. Any cost you cannot account for is almost certainly a missing occurrence or unlinked order.

Master data vs. project data

The Customer, Project Type, and Tags used on a project come from master data — they exist independently and can be reused across many projects. The tasks, budgets, risks, chances, and reports are project-scoped: they were created for this project and live only here. See Master Data vs. Project Data for the full distinction.