Other Things a Node Can Be
A Project Board looks like a schedule, and most of the time that is exactly what it is being used as. But a node is a more general object than a task: a named span of time, with a start and an end, a set of dependencies on other spans, and a record of what actually happened to it. Nothing in that description says construction, or software, or any particular kind of work.
What follows is not a list of features. It is the same product, with the node pointed at something other than a piece of work. Three cases where Novus does the arithmetic, and then a longer list where it mostly just holds the shape.
A bid price
A contractor pricing a job is pricing time as much as work. Suppose there is $3.1 million of fixed direct work, and then eighty days of site overhead at $9,000 a day, twenty-five days of crane at $12,000, forty days of temporary facilities at $2,000. The direct work costs what it costs. Everything else is a rate multiplied by a duration, and the duration is a property of the sequence.
So two proposals containing identical work produce different prices. A hundred and ten days with little overlap is a different bid from ninety-two days with controlled overlaps, which is a different bid again from eighty-six days bought with delay risk you may not want. Novus draws the difference: which sequence finishes sooner, which overlaps you have allowed, and which activities actually control the finish date.
It does not price it. There is no cost field on an activity and no rate table anywhere in the product — you supply every dollar. What the board gives you is the number those dollars get multiplied by, and a way to see it change when the sequence does. That is a smaller claim than pricing software makes, and a more useful one than a Gantt chart makes.
A cash-release gate
Name a node for the thing that releases money rather than the work that earns it — client acceptance, a milestone certificate, a stage sign-off. It has a date because everything on the board has a date, and it has predecessors because it genuinely does.
Now the useful part is not the node, it is what happens to it. When an activity upstream overruns, Novus works out what is waiting on it and puts a card up naming the delay and the activity that caused it. If the gate is downstream of that activity, the card is telling you when you can invoice. Nobody had to connect the schedule to the cash position; the dependency already did it.
A risk-exposure window
Some things are not work at all. A building operating without its backup generator is not a task anyone is performing — it is a condition that is true for a number of days, and the number matters.
A node is a good shape for that, because Novus already treats a span as something that opens, runs longer than expected, and closes. A Notice on it records that the exposure grew and why. Resolving it records that the exposure ended and returns the time. When it is over you are left with something most organisations never have: a dated record of exactly how long they carried a risk, written at the time rather than reconstructed afterwards.
Where the line is
Two of those three work because an engine acts on the node — the push engine moves the cash gate, the notice lifecycle opens and closes the risk window. That is the test worth applying to any of this. If the only thing Novus contributes is drawing a bar with a name on it, a calendar would have done, and you should be suspicious of the idea.
It is also worth saying plainly what is not here. Novus holds no money, so anything financial is your arithmetic against its dates. And it does not compare one Project Page against another, so it cannot yet tell you what a supplier normally takes or what your real production rate is across jobs. That is a different product, and it is called MetricsOS.
Other things a node has been
Without commentary, because the point is to make you think of your own rather than to claim any of these:
- Schedule health bar — “Launch contingency — 14 days.” Delays eat the buffer; what is left is the protection you still have.
- Liquidated-damages clock — “Contract completion — $80,000/day after the deadline.” Drift on the roll-up stops being an abstraction.
- Inventory health bar — “Battery inventory — 18 days of coverage.” The replenishment chain has to land before the bar runs out.
- Service-level clock — “Respond to a safety incident within 24 hours.” The grace period and the overdue notice do the watching.
- Decision-latency measurement — “Design submitted → owner decision.” How long approvals actually take, and at which level the waiting happens.
- Warranty clock — “Equipment warranty — 24 months.” Inspection and replacement get scheduled before cover lapses.
- Regulatory window — “Permit valid until 30 September.” Everything that must happen first becomes visible against it.
- Queue-aging bar — “Customer security review.” Every open request becomes a timed object, and the old ones stop being invisible.
- Experiment window — “Run the pilot to 500 observations.” Preparation, measurement, review and the decision to scale are separate spans, linked.
- Recovery reserve — “Commissioning allowance — seven days.” You can watch yourself spend the reserve before the contract date moves.
- Market-entry clock — “Launch before the regulation changes.” Product, legal, localisation and distribution converge on one date that is not yours to move.
None of these needed a feature adding. They needed somebody to decide that the thing worth tracking was a span of time, and then to be honest about what it depended on.
Mahesh