Monument

Understanding the Project Hierarchy

How Monument organises work into projects, phases, stages, and tasks with unlimited nesting depth.

Overview

Monument uses a flexible hierarchy to organise project work. A project contains tasks that can be nested to any depth — allowing you to model the natural structure of an architecture project.

The Hierarchy

A typical architecture project uses this structure:

Project (e.g. "Smith Residence")
├── Phase (e.g. "Schematic Design")
│   ├── Stage (e.g. "Site Analysis")
│   │   ├── Task (e.g. "Topographic Survey")
│   │   └── Task (e.g. "Soil Testing Report")
│   └── Stage (e.g. "Concept Design")
│       ├── Task (e.g. "Floor Plans")
│       └── Task (e.g. "Elevations")
├── Phase (e.g. "Design Development")
│   └── ...
└── Phase (e.g. "Construction Documentation")
    └── ...

There's no fixed limit on depth. Everything below the project is technically a task — the labels "phase" and "stage" are conventions based on the nesting level.

How Tasks Are Ordered

Tasks within the same parent are ordered by their position. You can reorder them by dragging in the project view or on the schedule. Monument uses materialized paths internally (e.g. 1.2.3 means the 3rd child of the 2nd child of the 1st top-level task), which enables fast hierarchy lookups and reordering.

Parent and Child Relationships

Parent tasks act as containers — their dates, hours, and financials can roll up from their children:

  • Dates: A parent's start date is the earliest child start; its end date is the latest child end.
  • Hours: A parent can show the sum of all child hours.
  • Financials: Revenue and cost items can aggregate up the tree using rollup formulas.

You can also set values directly on parent tasks — it depends on your preferred tracking approach.

Shell and Version Model

Behind the scenes, every project and task has two parts:

  • Shell — a stable entity with a permanent ID. This never changes.
  • Version — contains the actual data (name, dates, budget, etc.). When you save changes, a new version is created.

This enables baseline comparison — you can save a snapshot of your project plan and later compare it to the current state to see what changed. See Project Versioning and Baselines for more.

Task Statuses

Each task has a status that tracks its progress through the project lifecycle:

  • Pending — not yet started
  • In Progress — actively being worked on
  • Completed — finished
  • Blocked — waiting on something
  • Cancelled — no longer required

Your organisation can also define custom task statuses that map to these standard states.

What's Next