Demand

Dependencies · Data Nodes

Links to: AI agents (via REQUESTS_MEMBER), Cost centres (via ORIGINATES_FROM), OKRs (via ORIGINATES_FROM), People (via REQUESTS_MEMBER), Value creation (via ORIGINATES_FROM), Projects (via ORIGINATES_FROM), Roles (via ORIGINATES_FROM, REQUIRES_ROLE)

Linked from: Competences (via REQUIRES)

A demand states what is needed: how much capacity, over which period, for which activities and with which skills. It is the starting point of planning — see Demand & Resource Planning.

Purpose

Demands make visible what a goal, a project or a running value stream actually requires from people (and AI agents). Without them there is only a planned number against a reference object — and nobody can say whether it is covered.

A demand is deliberately homogeneous: one requirement, one quantity, one profile. If a project needs backend and UX, that is two demands on the same source. This keeps the model simple and makes partial coverage expressible.

Default view

The list view shows the tenant’s demands. From the detail page you reach the requirement profile (relationships) and the Coverage card.

Creating a demand

Sidebar “Demands” → button “New demand” in the top right → dialog “Create new demand”.

The dialog starts with the general fields (tenant, name, Customer ID, classification), followed by “Demand data” — the form generated from the entity type’s schema. The kind decides what is required:

Kind	Required fields	End date
Change (project, OKR)	Total demand (h), Valid from, Valid to	required — an initiative ends
Run (value stream, role)	Demand per period (h), Valid from	optional — operations do not end

The other quantity field is hidden, and a hidden field is never required. A name is optional, but it makes the demand easier to recognise in the backlog.

Save via “Save as draft” or “Save & publish” — like every change, a new demand goes through the tenant’s draft and approval path.

Relationships (where the demand originates, which role and which competences it requires) are set after creation on the detail page, not in the dialog. A demand without ORIGINATES_FROM is valid, but hard to place without its source.

Mind the cut: one demand = one homogeneous requirement. Two demands on the same source beat one that mixes two profiles.

No “Demands” menu entry? Then the tenant has no entity type using the demand module — see Entity Types. The “Resource planning” entry depends on it as well.

Important relationships

ORIGINATES_FROM (Demand → Value stream/Role/OKR/Project/Cost centre) — where the demand arises from. Value stream and role carry running operations, OKR and project the initiatives.
REQUIRES_ROLE (Demand → Role) — the activity axis: the role bundles what has to be done.
REQUIRES (Demand → Competence, with level) — the skill axis.
REQUESTS_MEMBER (Demand → Person/AI agent) — a named request, not an assignment.

Details: Relationship Types.

Schema to copy

{
  "type": "object",
  "properties": {
    "demandKind": {
      "type": "string", "title": "Kind",
      "enum": ["run", "change"], "default": "change"
    },
    "demandedHours": {
      "type": "number", "title": "Total demand (h)", "minimum": 0,
      "showWhen": { "field": "demandKind", "values": ["change"] }
    },
    "hoursPerPeriod": {
      "type": "number", "title": "Demand per period (h)", "minimum": 0,
      "showWhen": { "field": "demandKind", "values": ["run"] }
    },
    "activities": { "type": "array", "items": { "type": "string" }, "title": "Activities" },
    "startDate": { "type": "string", "title": "Valid from", "format": "date" },
    "endDate": { "type": "string", "title": "Valid until", "format": "date" },
    "granularity": {
      "type": "string", "title": "Period grid",
      "enum": ["month", "quarter"], "default": "month"
    },
    "distribution": {
      "type": "string", "title": "Distribution",
      "enum": ["even", "frontloaded", "backloaded"], "default": "even",
      "showWhen": { "field": "demandKind", "values": ["change"] }
    },
    "memberKind": {
      "type": "string", "title": "Who may cover it",
      "enum": ["any", "human", "agent"], "default": "any"
    },
    "demandStatus": {
      "type": "string", "title": "Status",
      "enum": ["open", "planned", "closed", "cancelled"], "default": "open"
    },
    "priority": {
      "type": "string", "title": "Priority",
      "enum": ["low", "medium", "high", "critical"]
    },
    "description": { "type": "string", "title": "Description" }
  },
  "required": ["demandKind", "startDate"],
  "allOf": [
    { "if": { "properties": { "demandKind": { "const": "change" } } },
      "then": { "required": ["demandedHours", "endDate"] } },
    { "if": { "properties": { "demandKind": { "const": "run" } } },
      "then": { "required": ["hoursPerPeriod"] } }
  ]
}

Two particularities of this schema:

allOf with if/then makes the requirement depend on the kind: an initiative needs a total and an end date, running operations need the quantity per period. See JSON Schema for Entity Types.
showWhen hides the respective other quantity field. A hidden field is never required — only that way does the combination avoid becoming a dead end.

Status is not coverage

demandStatus describes the life cycle (open, planned, closed, cancelled). Whether a demand is covered is computed and not held in a field — otherwise it would be the first number nobody keeps up to date.

Detail view

The detail page shows the demand data, the requirement profile in the relationships section, and in the Reports tab the Coverage card: demand, planned and open per period.

Demand & Resource Planning — Demand, plan and coverage at a glance
Running operations and initiatives — The two kinds and their quantity forms
The demand profile — three axes — The three axes of the requirement profile
Roles — Roles as bundles of activities
JSON Schema for Entity Types — Schema options, showWhen, dependent requirement