Work a project's schedule

Anchors, the permit lattice, the task tracker and the critical dates for one project, on one page.

A project's schedule is one page with four sections, in the order the work happens. Anchors are the events and contracts every rule below refers to. Clocks are the permit lattice for this project. Tasks are the tracker view, grouped, with plan against actual. Critical dates are the deadlines that carry a consequence, banded by how soon they land.

A jump bar under the header moves between the four, because one long page only beats two tabs if a thumb can get around it.

Setting a new project up

A project created from the overview lands here with nothing on it, so the top of the page carries a short list of what a deal needs, in the order a developer usually does it: the address, the lifecycle and billing stage, the anchors, the budget, the lender and builder, the documents, and the schedule itself. Each line links to the panel that does it.

Nothing on that list is a gate. Every tab opens whether or not a line above it is finished, there is nothing to tick, and a line goes green because the thing exists: an address is on file, a cost code is entered, a task is on the schedule.

It is a first-run card and it behaves like one. It leaves for good the moment somebody starts working the deal, meaning the first task, cost code or document, whether or not the rest of the list is finished, because a card titled "setting this project up" on a deal five weeks in is a nag rather than a path. It also leaves once every line is green, and a project imported complete never sees it at all. Dismiss hides it for you on this project without marking anything done.

A line whose answer your access cannot read is left off the list rather than shown as outstanding: without budget access there is no budget line to chase, because "no budget yet" would not be a true thing to say to you.

The project menu

Rename, Import, the stage move, Archive and Delete sit behind Project ⋯ in the project header card, on the same row as the name. The header is on every tab of a project, so archiving a deal or moving one to the active stage is reachable from Budget and Documents rather than only from this page.

Anchors and the cascade

An anchor is a real event: a contract signed, a plat recorded, an approval issued. Dates below it are not typed. They are stated as a rule against the anchor, for example thirty business days after recording.

Move the anchor and every date derived from it moves. Nothing is retyped and nobody has to be told. That is the most useful thing this page does, and it is why importing a plan as rules is worth more than importing it as values.

Every move leaves a receipt at the top of the page: what changed, and how many dates recomputed because of it. A long cascade lists the first sixty and says "showing 60 of 200" so the sixty do not read as the whole of it. Only the most recent change can be put back with Revert, and only while the anchor still holds the date the cascade left it on. If something newer has moved on top, or the event or task the receipt names is already gone, Revert says so and stops offering rather than restoring a date that no longer fits.

When a rule cannot land where its plain reading would, the row says so beside the rule. A date held back to an outside date reads "capped at outside date", and one pushed out through a stop-work reads "tolled N d", so a countdown is never printed next to a date it does not match.

Reading a long task list

A couple of hundred rows is a schedule, not a list. The filter pills above the table cut it to what is late, what has no plan, what is still open, and what is done. Above a threshold the groups arrive folded, because a long imported schedule wants to be navigated rather than read.

The same pills sit on the critical dates register below, so both surfaces are worked the same way.

Starting from another project's schedule

A schedule can be copied in from another project to start from a plan somebody already trusts, but only into a project with no tasks yet. Groups, task names and rules copy, and a rule that pointed at another task is re-pointed at the copy. A fixed calendar date does not copy, and neither does an outside-date cap or a tolling period: those name specific days on the source project's calendar and would be wrong here, so the task copies with no plan for you to re-anchor rather than carrying a confident wrong date across.