Derived versus declared

Two different kinds of fact live side by side in OTB Works, and they behave differently on purpose. Not knowing which is which is the single most common source of “why won’t it let me type that” confusion.

Derived: worked out, never typed

A derived value is calculated from other things, every time it’s shown. Nobody types it in, and there is nowhere to type it in, the field simply isn’t editable, because there is no single correct place to store a number that’s really a consequence of other numbers.

The clearest examples:

• A deliverable’s dates are the earliest start and latest end of its own steps. A work package’s dates are the same rule one level up, over its deliverables. You cannot set a work package’s dates directly once it has dated deliverables, the product doesn’t silently accept a value and quietly overwrite it either; it refuses the write outright.
• Effort is entered only on steps. A deliverable’s effort is the sum of its steps (with a specific rule for steps nobody has sized yet, see below). A work package’s effort is the sum of its deliverables. There is no “effort” box on a work package to type into.
• Percent complete rolls up the same way, weighted by effort at every level , not a plain average. A step that’s marked done always reads 100%, no matter what was typed into it before; a step that’s not started always reads 0%, even if it has a stale value left over from being dragged around earlier.
• Status (Not started / In progress / Behind / Overdue / Done) is pure arithmetic on dates and progress, never something a person picks.

Why a deliverable never has zero steps

Because effort, dates and percent complete are always derived from steps, a deliverable is never allowed to exist with no steps at all, if it did, there’d be nothing to derive anything from. The moment a deliverable would otherwise have no steps (when it’s first created, or if you delete its last remaining step), the product creates one implicit step in its place automatically, carrying whatever dates, effort and progress the deliverable would otherwise have shown. You’ll see this as a single, unnamed placeholder row in the steps table, turn it into (or replace it with) real, named steps as soon as you know what they are; it behaves exactly like an ordinary step in every calculation until then.

Unsized steps don’t drag the total to zero

If some of a deliverable’s steps have an effort figure and others don’t yet, the unsized ones are weighted as the average size of the sized ones, not zero. This is a deliberate fix for a real complaint: nine trivial two-day steps and one un-estimated forty-day step should not read as “90% planned” just because nobody’s put a number on the big one yet.

The headline number is what’s actually recorded, not the estimate

Wherever you see an effort total, the number in front of you is the recorded total, the days actually entered, not padded out with the imputed average for unsized steps. The estimate (recorded + imputed) still drives the underlying maths (dates, percent complete, the rollups above), but the display always says something like “6 days recorded across 2 of 4 steps,” never presents an estimate as if it were a fact someone actually entered.

Declared: a person asserts it, and it always has to say why

A declared status is different: a person actively says “this is blocked,” “this is on hold,” “this is awaiting a decision,” or “this is awaiting sign-off.” Unlike a derived status, this can never be worked out from dates alone, only a person knows that a deliverable is stuck waiting on a supplier’s decision.

But a declared status is never a free-floating mood. Every one of them:

• Must name a cause: a RAID item (a risk, issue, dependency, action or decision). If one doesn’t already exist for what you’re pointing at, declaring the status creates one for you in the same action.
• Must have an owner and a review date. Declaring “Blocked” specifically pre-fills the review date to a week from today as a starting suggestion, you can change it, but it’s never left blank.
• Doesn’t clear itself. If the RAID item it points at gets closed, the declared status is not automatically removed, it’s flagged as needing review, so a person has to look at it and decide to actually clear it. The product would rather show you something slightly stale and flagged than silently make a concerning status disappear on its own.
• Shows upward, but isn’t copied upward. If a deliverable is blocked, its work package visibly reflects that (you’ll see it in the reasons behind the work package’s own status pill), but there’s no separate “blocked” record created on the work package itself. The one declaration lives where it was actually made.

A real example, from the product’s own demo data

In the demo programme, the Firewall Estate Consolidation work package reads Overdue. Drilling into why shows the actual chain of causes: its Site-by-site migration deliverable is 8 days overdue on its end date, a derived fact, and, nested underneath that same reason, its “Site 1 (HQ) cutover” step is separately declared blocked, pointing at a specific RAID item, with red escalation. Both are shown together, each with its own sentence and its own link back to the thing that caused it: an arithmetic fact about a missed date, and a person’s own statement that something is stuck, sitting side by side rather than one hiding the other.

How the two combine on one pill

A status pill you see on screen, say, on a work package, can be influenced by both kinds of fact at once, and the product is explicit that they don’t compete: the derived verdict (worked out purely from dates and progress) is never changed by a declared status. What can change is the colour you see: each declared-status type has its own escalation setting (none, amber, or red, an administrator can tune this), and the pill shows the worse of the derived colour and the worst open declared status’s escalation. If something is both genuinely behind schedule and has a declared blocker, you’ll see both reasons listed together, not one hiding the other.

Why it matters in practice

If a field won’t accept your typing, it’s very likely a derived one, check whether the underlying steps or deliverables need updating instead. If you need to flag a problem that dates alone can’t express, waiting on someone, stuck, blocked , that’s a declared status, and the product will always ask you to name why, not just let you pick a colour.

Where to go next

• A sitting: a derived field can never be the target of a change you propose; only stored, declared fields can be.
• The Deliver section, for where to enter steps, dates and effort day to day.
• The Steer section, for how these combine into the dashboards a delivery lead or board reader actually looks at.