Demand management is the discipline of capturing every request that could become a project, assessing it on a consistent basis, and weighing it against the organization's real capacity to deliver, before anyone commits resources. It is the front door of a project portfolio. Get it right and the portfolio contains the work that matters most. Get it wrong and capacity leaks into whatever arrived loudest, and the strategic work never gets funded.
Most PMOs discover they have a demand problem before they have a delivery problem. Teams are busy, yet the initiatives leadership cares about are late or unstarted, because unmanaged demand let a hundred small requests crowd out the few large ones. Demand management is the control that stops that.
Key takeaways
- Demand management captures, categorizes, assesses, and prioritizes all potential work against capacity, before commitment. It governs what is allowed to become a project.
- It is broader than intake. Intake is the mechanism that receives a request; demand management is the discipline that decides, across all requests, what the portfolio should hold.
- Every request must land in one consistent pipeline. Demand that arrives through side channels and personal favors is the demand that breaks a portfolio.
- Demand is only half the equation. It is meaningless without a capacity figure to weigh it against, which is why demand and capacity planning are two halves of one decision.
- In portfolio management, demand management refers to project demand, not supply-chain demand planning or forecasting. They share a name and nothing else.
- The output is a prioritized, capacity-aware pipeline that feeds portfolio governance, not a pile of approved requests with no owner of the trade-offs.
What is demand management in project portfolio management?
Demand management in project portfolio management is the process of gathering all potential and active demand for an organization's delivery capacity, evaluating each request against strategy and against available capacity, and shaping it into a prioritized pipeline of work the portfolio can actually execute. It sits at the start of the portfolio lifecycle, upstream of selection and delivery, and its job is to make sure the portfolio is fed the right candidates in the first place.
The word demand is deliberate. It signals that requests are not automatically projects. They are demand on a finite supply of people, money, and time, and like any demand exceeding supply, they have to be prioritized and rationed rather than simply accepted.
What are the steps in the demand management process?
The demand management process runs in six steps, from a raw request to a decision that respects capacity:
- Capture. Route every request through one channel with a consistent minimum of information: the problem, the sponsor, the expected value, and a rough size. One front door, no exceptions.
- Categorize. Tag each request by type (strategic, run-the-business, maintenance, regulatory, unplanned) so like is compared with like and mandatory work is visible.
- Assess. Evaluate value, strategic fit, risk, and rough cost on a common scale, enough to rank, not enough to over-invest in ideas that will be declined.
- Prioritize. Rank the assessed demand using consistent criteria, so the order reflects value and fit rather than who asked most insistently.
- Weigh against capacity. Draw the line where delivery capacity runs out. Everything below the line is the honest backlog, not a promise.
- Decide and route. Approve, defer, or decline each item, and pass the approved, capacity-aware pipeline into governance for funding.
The mechanics of receiving and logging a single request, the forms, the triage, the request record, are covered in the project intake process, with the request form itself broken down in the project intake form guide. Demand management is the layer above that: what to do with all the requests once they are in.
What is the difference between demand management and intake?
Intake is the mechanism that receives, logs, and triages an individual request; demand management is the broader discipline that assesses and prioritizes the whole body of requests against capacity and strategy. Intake is a step. Demand management is the ongoing balancing act that intake feeds. Put simply, intake handles one request at a time, and demand management handles all of them together. The staged flow those requests move through, from idea to delivery, is the project pipeline.
The distinction is practical, not academic. A PMO can have an excellent intake form and still have terrible demand management, if every well-logged request is then approved without anyone asking whether the portfolio has the capacity to deliver the sum of them. The intake queue fills up, everything is technically approved, and delivery quietly falls apart. Good intake without demand management is an orderly path to overcommitment.
How is demand management different from demand planning in supply chain?
They share a name and nothing else. Demand management in project portfolio management is about managing requests for project and delivery capacity. Demand planning in supply chain is about forecasting customer demand for products so that inventory and production can be planned. One deals with which projects to do; the other deals with how many units to make. If you arrived here looking for forecasting, inventory, or sales-and-operations planning, this is the wrong discipline.
The confusion is worth flagging because search results mix the two constantly, and some PPM tools (ServiceNow's strategic portfolio management, for example) use "demand management" as a named module for exactly the project-request sense described here. In a PMO context, demand always means demand on delivery capacity.
What types of demand does a portfolio have to manage?
Not all demand is discretionary, and treating it as if it were is a fast way to lose credibility. A portfolio typically carries five types, and only some are genuinely a choice.
| Type | What it is | Discretionary? |
|---|---|---|
| Strategic | New initiatives that advance business goals | Yes, the real prioritization battleground |
| Run-the-business | Enhancements that keep existing capabilities current | Partly |
| Maintenance | Keeping the lights on, small fixes, upkeep | Largely not |
| Regulatory | Compliance and legal mandates with deadlines | No, non-negotiable |
| Unplanned | Urgent requests that arrive mid-cycle | Case by case, needs a reserve |
Swipe to see more →
The insight most portfolios miss is that mandatory demand (maintenance and regulatory) consumes capacity first, and only the remainder is available for the strategic work everyone actually argues about. Show leaders that the discretionary budget is 40 percent of capacity, not 100 percent, and the prioritization conversation gets a lot more honest.
How does demand management connect to capacity?
Demand management is one half of a single decision, and capacity planning is the other. A ranked list of demand is worthless without a credible figure for how much the organization can actually deliver, and a capacity figure is worthless without prioritized demand to spend it on. The two have to be read together, at the same table, or the portfolio commits to more than it can do and calls the shortfall a delivery failure when it was really a demand failure.
The line where prioritized demand meets available capacity is the single most important number a PMO produces. Above it is what gets done; below it is the honest backlog. Setting that line requires real capacity data, which is the subject of resource and capacity planning, and the decision to fund what sits above the line belongs in portfolio governance, where leaders own the trade-offs on the record.
The demand ratio shows how much more is asked than can be delivered
One number tells you whether your demand problem is a prioritization problem or an expectation problem: requests received in a period divided by requests the portfolio can actually start in that period. A PMO receiving 40 requests a quarter and starting eight is running a demand ratio of 5 to 1. No scoring model fixes a ratio like that, and pretending otherwise is why intake processes get rebuilt every two years.
Count both sides honestly. Requests received means everything that arrived asking for delivery capacity, including the ones that got waved through informally. Requests started means initiatives that actually began, not ones that were approved and joined a queue. Read the ratio against your own trend rather than a published benchmark, because it depends entirely on how large your requests are and how open your front door is.
| Demand ratio | What it usually indicates | Where the fix belongs |
|---|---|---|
| Close to 1 to 1 | Either healthy, or requests are being filtered before they reach you | Check whether work is bypassing intake before celebrating |
| 2 to 1 or 3 to 1 | Normal for a functioning portfolio. Prioritization is doing real work | Nothing. This is what the process is for |
| Above 4 to 1 | The organization believes it has far more capacity than it has | Publish the line. This is a communication problem, not a scoring one |
| Above 8 to 1 | Intake has become a suggestion box and nobody trusts the outcome | Raise the bar to submit, and decline explicitly rather than deferring |
| Rising quarter over quarter | Deferrals are accumulating and being resubmitted | Enforce a decline rule so the same request stops recirculating |
Swipe to see more →
The ratio is most useful as a conversation opener with executives, because it converts a complaint into arithmetic. "We are being asked for five times what we can do" is a statement leadership can act on. "We are very busy" is not. It also protects the PMO from the accusation that it is slow, by relocating the problem to where it actually sits, which is the volume of things being started rather than the speed of delivery.
Shadow demand is the work that never enters the pipeline
The largest source of demand in most portfolios is not in the pipeline at all. It is the small requests that get done as favors, the two-day changes that never justified a form, the analyst who spends every Friday on something no register knows about. Individually each is too small to govern. Collectively they routinely consume a fifth to a third of the capacity the visible pipeline assumed it had, which is why carefully planned portfolios still finish late.
You can measure it without a timesheet regime. Take the capacity you allocated to approved projects for a period, take the actual capacity consumed by those projects, and take total available capacity. The gap between total available capacity and what the approved projects consumed is the space shadow demand lives in. If you allocated 900 person days, the projects consumed 640, and the teams were fully occupied all quarter, roughly 260 person days went somewhere that has no record.
Naming it changes what you do about it. The instinctive response is to route everything through intake, which fails immediately, because a form that takes twenty minutes will never be used for a two hour request and the work simply becomes better hidden. Three responses actually hold up.
| Response | How it works | When to use it |
|---|---|---|
| Reserve capacity for it | Plan only against net capacity, with the measured shadow share deducted up front | Always. This is the baseline move |
| Give it a fast lane | A one-field request under a size threshold, logged but not scored | When the small work is legitimate and recurring |
| Name an owner and a cap | One team or person absorbs it within a fixed weekly allowance | When it clusters around a few individuals or systems |
Swipe to see more →
The point is not to eliminate shadow demand. Much of it is useful and responsive work that a rigid portfolio process would ruin. The point is to stop planning as though it does not exist, because a plan built on gross capacity is wrong by exactly the amount of work you never counted, and it will be wrong by that amount every single quarter.
How much capacity should you reserve for unplanned demand?
Reserve the share your own last four quarters actually consumed, not a rule of thumb borrowed from a book. Go back through the period, identify the work that was not in the approved plan at the start of it, total the effort it took, and express that as a percentage of capacity. That figure is your reserve, and it is usually larger than anyone expects.
Different demand types justify very different reserves, and the mistake is holding one number for all of them. A team carrying production support alongside project work has a structurally higher unplanned share than a team doing pure delivery, and giving both the same 10 percent buffer guarantees one is overcommitted and the other is idle. Work it out per team or per capacity pool, not once for the portfolio.
Two rules keep the reserve honest. First, the reserve is spent, not saved: if unplanned work does not arrive, that capacity gets released to the next item on the ranked list rather than absorbed silently. Second, review the percentage every couple of quarters against what actually happened, because a reserve set once and never checked drifts into either a permanent overcommitment or a permanent hiding place. If your reserve is consistently unused, it has become slack that nobody will admit to, and the number should come down.
What information does a demand record need to be assessable?
Enough to rank it and no more. Seven fields cover it: the problem being solved, the requesting sponsor, the expected benefit, a rough size, the desired timing, the demand type, and whether anything makes it mandatory. Anything beyond that is investment in a request that has not yet earned it, and it is the reason heavy intake forms suppress the good requests along with the weak ones.
| Field | Why it is needed | What "good enough" looks like |
|---|---|---|
| Problem statement | Distinguishes a need from a preferred solution | Two or three sentences on what is wrong today |
| Sponsor | Someone accountable who can free people and money | A named individual, not a department |
| Expected benefit | The value side of any ranking | A rough figure or a clear category, not a business case |
| Rough size | Locates it against capacity | A band such as small, medium or large, defined in your own terms |
| Desired timing | Separates genuine dates from general urgency | A date with a reason, or no date at all |
| Demand type | Lets like be compared with like | One tag from a fixed short list |
| Mandatory basis | Prevents everything being labeled must-do | A named regulation, contract clause or audit finding, or blank |
Swipe to see more →
The last field does more work than the other six combined. Ask for a specific legal, contractual or audit source and the proportion of requests marked mandatory falls sharply, because most of them were mandatory in the sense of strongly desired. Leave the field as a checkbox and a third of your portfolio becomes unprioritizable overnight.
How do you tell a sponsor their request is below the line?
Give a specific answer with a date attached, and say which constraint decided it. "Not this quarter, reconsidered in the January cycle, because the two initiatives above it consume the platform team through December" is a sentence a sponsor can plan around. "It is in the backlog" is what teaches people to route their work around you next time.
What makes this conversation survivable is that the sponsor can see the same list you did. Publishing the ranked list, the cutoff, and the capacity figure behind it moves the discussion from a decision you made about their project to a constraint they can see and argue with. Most sponsors accept a no they can inspect. Almost none accept a no they have to take on trust, and the ones with the most organizational power accept it least, which is precisely how side channels get established.
Be careful with the word yes. Approving something into a queue with no start date is heard as a commitment and reported upward as one, and it is the most common way a portfolio ends up with three times more committed work than it can deliver. If it is not starting this period, the honest words are deferred or declined, and both need the reason and the next review point.
Where demand management breaks down
Demand processes rarely fail loudly. They erode, in a few predictable ways, until the pipeline is a record of requests rather than a control on what gets started.
| Pattern | Symptom | Correction |
|---|---|---|
| A second front door | Work appears in delivery that intake has never seen | Trace one such item back to its origin publicly, then close that route |
| Deferral as the default answer | The backlog grows every cycle and nothing leaves it | Two deferrals equals a decline and a required resubmission |
| Assessment before triage | Weeks spent building cases for requests that were never viable | A cheap first filter that kills obvious no items in days |
| Everything tagged mandatory | Most of the pipeline is exempt from prioritization | Require a named regulation, clause or audit finding |
| Demand reviewed without capacity present | Approvals exceed delivery every period, and nobody notices until delivery slips | Never review demand without the capacity figure in the same room |
| The pipeline is never pruned | Requests from two years ago still sit in the list, distorting every count | Age out anything untouched for a year, and tell the sponsor you did |
Swipe to see more →
Why does demand management matter in a PMO?
Demand management matters because it is the earliest and cheapest point at which a PMO can influence the portfolio. Every control downstream, prioritization, resourcing, governance, is more expensive and more contentious than simply managing what is allowed to enter. A PMO that only manages projects after they exist is firefighting; a PMO that manages demand shapes which fires ever get lit.
It is also where the PMO earns its strategic seat. Anyone can run a status report. Being the function that can say, with data, "here is everything being asked of us, here is what we can actually deliver, and here is what that means we must not do," is what makes a PMO worth having. Demand management is the front end of the whole project portfolio management process, and it defines the shape of the project portfolio everything else then manages.