Demand & Resource Planning
A demand states what an initiative or running operations need: how much capacity, over which period, for which activities and with which skills.
Purpose
Section titled “Purpose”Before, there was only a number: “120 hours are planned for this project”. Where the effort came from, what had to be known to deliver it, and whether anyone was actually available — none of that was recorded anywhere. Demands close exactly that gap and make a chain visible:
Demand (what is needed) → Plan (who takes on how much) → Coverage (what stays open).
Alongside it, deliberately separate, Effort Booking continues to answer a different question: what was actually worked. Mixing the two would be convenient and wrong — planned capacity and recorded working time are different statements with different consequences.
Where a demand comes from
Section titled “Where a demand comes from”From two sources of equal standing:
- from an initiative — an OKR or a project. Time-boxed, with a total quantity.
- from ordinary, day-to-day value creation — a value stream that has to be served, or a role that must stay filled. Ongoing, with a quantity per period.
The second case is the larger one in most organisations. Planning that only knows about initiatives spends the running operation a second time — with the familiar result that projects fail “because day-to-day business got in the way”. More on this: Running operations and initiatives.
What belongs to a demand
Section titled “What belongs to a demand”| Field | Meaning |
|---|---|
| Kind | Running operations or initiative — decides which quantity applies |
| Quantity | Total hours (initiative) or hours per period (ongoing) |
| Period | Valid from, and for initiatives also valid until |
| Activities | What has to be done — usually via a required role |
| Competences | What has to be known for it, with a minimum level |
| Who may cover it | Human, AI agent, or both |
The three axes of the demand profile — activity, skill and availability — are described under The demand profile — three axes.
Demands are created and described in the demand list: sidebar “Demands” → “New demand”. The click path and the required fields per kind are documented under Demand. The cockpit only assigns demands — it deliberately has no creation path.
Reading the coverage
Section titled “Reading the coverage”On a demand’s detail page the Coverage card shows three numbers per period: Demand, Planned and Open. It is computed, not stored — a stored coverage figure would be the first one nobody keeps up to date.
“Cannot be quantified” is not zero. If a demand lacks its start date or its quantity, the card says so explicitly instead of drawing a line along zero. This can happen because the entity type’s schema belongs to the tenant and can lose fields — see JSON Schema for Entity Types.
What this is not
Section titled “What this is not”- Not time tracking. A demand states what is needed, not what someone worked.
- Not surveillance. Utilisation is a planning view, not a monitoring view.
- No automatic allocation. The system proposes and explains; people decide.
Asking the assistant
Section titled “Asking the assistant”rALPH can read demand planning — with your permissions, not more. It answers four questions directly:
| Question | What it returns |
|---|---|
| “What is still open?” | the backlog, period-by-period for run demands |
| “How covered is demand X?” | demand, plan and open per period |
| “Who could take this on?” | candidates on all three axes, with reasons |
| “What has slipped?” | coverage that fell without a plan change — only with demand:report |
Two things that deliberately hold here:
- It is not a more convenient way around access control. What you cannot see in the interface, it will not name either; if you lack the reporting permission, it says so instead of answering.
- It does not compute its own numbers. It calls the same analysis the interface calls — otherwise you would get a different figure depending on the route, and both would look plausible.
It can create a demand too, but only as a draft: it goes through the approval mode like any other change.
Related
Section titled “Related”- Running operations and initiatives — Running operations and initiatives compared
- The demand profile — three axes — The three axes: activity, skill, availability
- Demand — The “Demand” entity type in detail
- Effort Booking — The actuals side: recorded effort
- Reports tab — Where analyses appear on an entity