Parent and Child Projects

Some projects are simply too big to sit comfortably as one record. A rail corridor spanning dozens of sites, or a development with hundreds of plots to stake out, can end up with an unwieldy list of proposal items that's hard to review and painful for your team to navigate when logging time.

Parent and child projects let you break a large project into a collection of smaller, self-contained ones (grouped under a single parent) while still seeing the whole thing together where it matters.

Think of it exactly like grouping proposal items, but one level up: instead of grouping items inside a project, you're grouping whole projects under a parent.

When to use it

Parenthood is worth considering when:

A single project has grown to hundreds or thousands of proposal items.
The work naturally divides into lots, phases, or sites that could each stand alone.
Different parts of the job are billed to different clients.
Different parts have different site locations and mapping information.
Your team struggles to find the right proposal item when recording timesheets, because the list is so long.

If none of those apply, a normal single project is still the simpler choice, you don't need to split every project.

How it works

A parent project can have any number of child projects.
Nesting is one level only. A child cannot itself have children, and a project that already has children can't be turned into someone else's child. (No grandchildren.)
Each child is a full project in its own right: its own proposal items, its own tasks, its own timesheets, its own site address and mapping, and, if you need it, its own client.
The parent gives you a single place to see everything grouped together.

What a child can have that's its own

Aspect	Behaviour
Proposal items	Each child has its own, kept separate from its siblings and the parent.
Client	A child can be billed to a different client from the parent.
Site address & mapping	Each child carries its own location and map geometry.
Tasks & timesheets	Logged against the child, so your team only sees that lot's tasks.
Naming	Name each child however suits, by lot, phase, area, and so on.

Setting it up

You link projects into a parent-child relationship by setting a project's parent. There are two natural ways to work:

Option 1: create the children, then group them. Create each lot as its own project as you normally would, then set the parent on each one to point at the project you want to act as the parent.

Option 2: start from the parent. Create (or pick) the project that will act as the parent, then create each child and set its parent to that project.

Either way, the key action is the same: on a project, set its Parent to the project that should sit above it. To detach a child again, simply clear its parent.

The rules Kompass enforces

To keep the grouping sensible, Kompass checks a few things when you set a parent. If one isn't met, you'll see a message explaining why.

One level only. You can't set a parent that is itself a child, and you can't give a parent to a project that already has children of its own.
A project can't be its own parent.
Same organisation. A parent and its children must belong to the same organisation (office). This also keeps them on the same currency. If you need to move a project to another organisation, detach it from its parent (or move/detach its children) first.
Stage order. An active child can't sit under a parent that is already further along than it. For example, you can't attach an in-progress child to a parent that's already been delivered or invoiced. You'd need to reopen the parent first. Quotes are more relaxed: a quote can sit under a parent that's still at quote or active stage, but not under one that's already finished or closed.
Accepting a child quote. Following on from the stage rule: if a child is still a quote, you can't accept it while its parent is already finished or closed. Reopen the parent first.

Note: deleting is protected too. A parent that still has children can't be deleted until those children are reassigned to another parent or deleted first. This is deliberate, so you never lose track of a child by removing its parent out from under it.

How acceptance flows up

A parent project's accepted status can come from its children. If a parent has no accepted proposal items of its own, it takes its acceptance from the earliest accepted child. In other words, as soon as the first child is accepted, the parent is considered accepted from that date.

If the parent has its own accepted proposal items, those take precedence and it doesn't derive anything from the children.

You don't need to do anything to make this happen. Kompass keeps it in step automatically as children are accepted, reopened, attached, or detached.

Viewing parents and children in the list

On the projects list, a parent project can be collapsed or expanded using the arrow on its row.

Collapsed, the parent row shows combined totals for itself and all its children. Price, quoted/accepted/open amounts, hours, status, and so on. These totals always reflect every child, even children that sit on another page of the list or are hidden by your current filters.
Expanded, you see each child on its own row with its own values.

A couple of helpful behaviours:

Searching automatically expands parents so you can see the matching child. If a child matches your search, Kompass shows it under its parent.
If your filters are hiding some children that still count toward a collapsed parent's totals, Kompass tells you, so the numbers never look wrong without explanation..

The payoff for your team

The biggest day-to-day win is for the people recording their time. Instead of scrolling through an enormous single list of proposal items to find the right one, they only see the proposal items for the specific child project (lot) they're working on. Smaller lists, less hunting, fewer mistakes.

And for whoever's managing the work, the parent gives you the bird's-eye view, the whole job's totals in one place, without losing the ability to drill into any single lot.