Demand Management for PMOs: Requests to a Pipeline

Without demand management, the loudest sponsor wins. Not the strongest business case, not the best-timed request, whoever escalates hardest or has the most tenure to spend on convincing the PMO director over coffee. The portfolio fills with pet projects that never had to justify themselves against anything, because nothing was ever screened before it landed on the delivery schedule.

Demand management is the process that turns incoming project requests into a scored, capacity-checked pipeline before anyone commits delivery resources to them. It runs on three pieces: one intake front door every request goes through regardless of who's asking, a lightweight scoring model that ranks fit and urgency, and a capacity check that turns "maybe eventually" into an honest not-yet with a real re-review date.

Direct answer: Demand management works by giving every project request the same front door, the same scoring rubric, and the same capacity check, so requests get approved on their merits instead of on who asked and how loudly. A request that clears the bar enters the pipeline; a request that doesn't gets a fast no, or a not-yet with a stated re-review date, instead of an open-ended maybe that quietly becomes a commitment anyway.

What Demand Management Actually Replaces

Most PMOs without demand management run on an informal version of the same idea: a sponsor emails the PMO director, the director sizes it up in a hallway conversation, and it either gets added to the queue or it doesn't. This works fine at low volume and breaks predictably as request volume grows, because the criteria live entirely in one person's head and change slightly with every conversation. Two requests with identical merit get different answers depending on who asked first, how the conversation went, and whether the director had budget top-of-mind that week.

Publishing the criteria fixes the inconsistency, but the real value is what it does to the requester's behavior. A sponsor who knows the scoring rubric in advance self-selects out of submitting a weak request, because the fast no is visible before they spend political capital defending it. That single change removes more low-value volume from the pipeline than any amount of PMO gatekeeping after the fact.

Building a Single Front Door for Requests

1. Route every request through one intake form, regardless of seniority or urgency. An exception process for "this one's different" is how the old hallway-conversation model creeps back in.
2. Capture only what intake needs: sponsor, the business problem in one paragraph, the deadline driver if there is one, a rough size estimate, and what happens if it isn't funded this cycle. Detailed scoping belongs after intake, not during it.
3. Set a response-time standard (five business days is typical) so requesters trust the process enough to use it instead of routing around it through a side channel.
4. Log every request, including rejections, so the PMO can show, at the end of a quarter, what came in and what happened to it. This is also what makes the scoring model auditable instead of a black box.

Scoring Requests Before They Become Projects

Intake scoring is deliberately lighter than the scoring a project gets once it's approved and enters full portfolio ranking. The goal at intake is a fast screen, not a precise forecast.

Dimension	What it captures	Fails the screen when
Strategic fit	Does the request map to a stated org priority, or is it solving a real problem outside that scope	The only justification offered is "it would be nice to have"
Urgency driver	Is there a real external deadline (regulatory, contractual, a dependency another team is blocked on) or is the deadline self-imposed	The stated urgency doesn't survive the question "what happens if this slips a quarter"
Rough size	A t-shirt estimate (S/M/L/XL) from someone who isn't the requester, so early sizing isn't optimistic by default	No one outside the requester's own team has looked at the ask

A request that clears all three moves to full scoping and, once scoped, the project portfolio prioritization model takes over, scoring the now-real project on value, confidence, and capacity cost against everything else competing for the same delivery capacity. Intake scoring and portfolio scoring are deliberately different models: intake is answering "is this worth spending scoping effort on," and portfolio ranking is answering "given everything we could fund, what actually gets funded."

The diagram below shows a request moving from submission through the score and capacity check to one of three outcomes.

Capacity-Aware Selection: Saying Not-Yet Instead of Never

A request that clears strategic fit and urgency can still fail on capacity, and that failure needs to be visible and time-bound, not a silent maybe that never gets revisited. Check the real delivery capacity available in the requested timeframe before approving, not the capacity a fully staffed team would have in theory. The resource capacity heatmap shows current utilization across the portfolio in about 30 seconds from a schedule export, which is the fastest way to answer "do we actually have room for this" honestly instead of optimistically.

When capacity is the blocker, not-yet beats no. State the re-review date (next quarter's planning cycle, or when a named project frees up capacity) so the requester knows this is a timing problem, not a rejection of the idea. A not-yet with no re-review date behaves exactly like a no, except it costs the PMO credibility when the requester eventually finds out it was never really coming back.

Running Demand Management Without Becoming the Bottleneck

The failure mode on the other side of "no process" is "too much process": an intake form so detailed it takes longer to fill out than the request is worth, or a scoring committee that only meets monthly and turns a five-day response standard into a six-week wait. Both train requesters to route around the process the same way an absent one does.

Keep the intake form to what a screening decision actually needs, not what a fully scoped project needs. Score against the fixed rubric, not a bespoke evaluation per request. And publish the pass rate and average response time the same way a phase-gate review should publish its own approval rate: a demand management process that approves everything isn't screening, and one that takes two months to say no isn't a front door, it's a second bottleneck wearing the first one's name.

Check your real capacity before the next intake cycle Run the free Resource Allocation Heatmap on your current portfolio to see actual utilization by week, so demand decisions are based on real capacity instead of a guess. → Open the Resource Heatmap