Glossary
What is demand management?
The practice of deciding what happens to requested work — shaping raw requests into decidable demands, refusing or parking some on the record, and committing the rest against real capacity.
It is distinct from intake, which collects requests, and from project management, which runs work already committed to. The test is exits: every request reaches a recorded outcome — planned, sent to a time-boxed discovery, parked with a review date, or declined with a reason — and none can simply be ignored in a queue.
Demand management vs project management
Project management runs work that has already been committed to: schedules, dependencies, status, delivery. Demand management is the layer before that — it decides whether a request becomes a commitment at all, and on what evidence. The two answer different questions: project management asks "is the work on track?", demand management asks "should this work have been promised, and was it ready to be?"
The boundary matters because most missed dates are decided at the demand layer, not the project layer. A request that became a commitment with no owner, no capacity figure and its open questions unexamined will slip regardless of how well the project is then run — the slip was built in before any tracker saw the work.
Demand management vs intake
Intake collects; demand management decides. An intake process — a form, a queue, a channel — gets requests through a door in a readable state. Demand management is everything that has to happen to them next: shaping the raw ask into something decidable, choosing an exit for it, sizing it against real capacity, and recording what was promised and why.
A team can have excellent intake and no demand management: requests arrive cleanly and then sit in a well-organised queue where nothing is ever refused, parked or committed on the record. The queue grows, the requests age, and every item in it is a decision nobody made.
The demand management process: four exits
A working demand management process is defined by its exits, not its stages. Every request must reach one of four recorded outcomes: it is planned and committed against capacity; it is sent to a time-boxed discovery with a deadline and a decision at the end; it is parked with a review date and the condition that would revive it; or it is declined with a reason the requester can read.
The fourth exit is the one that separates a real process from a queue. If a request cannot be declined on the record, the backlog becomes the place where refusals hide — and a backlog of unrecorded nos is the most expensive artifact in delivery, because every item in it is still being re-read, re-argued and quietly re-promised.
Related terms
- Demand — A work request that has entered the delivery lifecycle — the unit a delivery governance system tracks from intake to decision.
- Clarification brief — A short artifact that separates what is known from what is assumed from what is still an open question, produced when a raw request is shaped into a demand.
- Demand lifecycle — The path a work request takes from arrival to a closed outcome: Capture, Shape, Decide, Plan, Commit, Deliver, Learn — where a demand only walks the stages it needs.
This definition comes from building DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.