Common ServiceNow Demand Management Mistakes and How to Avoid Them

Demand Management turns business requests into a prioritised pipeline of projects, enhancements and support work, and most failures trace back to a few repeatable mistakes: intake that nobody understands, prioritisation that bends to the loudest voice, a portfolio weighted towards one kind of work, estimates and capacity that do not meet, weak governance, and demands that never connect to delivery. Each mistake below is described with its fix and how to prevent it, followed by the mistakes that hide inside a working process, a correction sequence for a portfolio that has drifted, and the signs the mistakes are being contained.

Mistake 1: Unclear intake process

Business stakeholders submit requests in different ways: email, phone, verbal (in a meeting), or tickets. No one knows how to submit a formal request. Requests get lost or are not prioritized consistently.

Fix: Define a single intake process: a form, a meeting, or a request channel. Make it clear and easy. Train stakeholders on how to submit. Route all requests through the same process.

Prevention: Start with intake process design before building Demand Management. Talk to requesters and understand their workflow. Make the process match their needs, not the other way around.

Mistake 2: Poor prioritization discipline

Priorities are set based on whoever asks loudest, not actual business value. Executive requests jump the queue. Requests are re-prioritized constantly, causing instability and rework.

Fix: Establish clear prioritization criteria: business value, urgency, dependencies, resource availability, and risk. Use a formal prioritization meeting (weekly or monthly) where criteria are applied consistently. Document decisions.

Prevention: Assign a prioritization owner who enforces the criteria. Have a formal governance committee that reviews and approves priority changes. Make re-prioritization expensive (in terms of effort and justification) so it happens only when truly necessary.

Mistake 3: Unbalanced portfolio

The pipeline is all urgent fixes and no strategic work, or vice versa. The portfolio is not balanced between maintaining systems and building new capabilities. Capacity planning is impossible because you do not know how much work is committed.

Fix: Define portfolio targets: what percentage of capacity should go to maintenance vs. new features vs. technical improvements? Monitor actual spend against targets and adjust intake to meet targets.

Prevention: Make portfolio balance a governance criterion. When a new request comes in, check the current portfolio balance. If maintenance work is already consuming most available capacity and your target is to allocate capacity more evenly, defer non-urgent new work until capacity opens up.

Mistake 4: Inadequate estimation and capacity planning

Requests do not have effort estimates, or estimates are wildly inaccurate. Without realistic estimates, you cannot plan capacity or commit to delivery dates. Delivery slips become a surprise.

Fix: Require estimates for all new requests before formal approval. Use historical data to calibrate estimates, comparing a new request with a similar piece of work already delivered and its actual effort. When delivery slips, compare actual to estimate and use that to improve future estimates.

Prevention: Track estimates vs. actual effort for every delivery. Use that data to improve future estimation. Make estimation a team skill, not a guess.

Mistake 5: Weak portfolio governance

The backlog grows indefinitely. Old, no-longer-relevant requests are never formally rejected. The backlog becomes unmanageable and no one trusts it. Decisions about what to build are not documented, so future team members do not understand the rationale.

Fix: Establish a governance process: quarterly portfolio review (what is in the backlog, is it still relevant, should we reject or deprioritize anything?). Formally reject requests that do not meet criteria. Document rejection reasons.

Prevention: Make the portfolio board review the backlog regularly. Archiving or retiring requests needs to be as formal as approving new ones. Set an expectation: if a request has not been approved or re-assessed within the review period your board agrees on, it is automatically deferred unless someone actively advocates for it.

Mistake 6: No linkage to delivery and execution

Demand Management prioritizes work, but delivery teams do not follow the prioritization. They work on what is easiest or what they prefer. Demand Management becomes a side process that no one uses.

Fix: Tie Demand Management to resource planning and project scheduling. Demand decides what is priority. Project scheduling pulls from the prioritized backlog. Resource allocation is based on the prioritized work. Make Demand Management the source of truth for what gets delivered.

Prevention: Integrate Demand Management with your project and portfolio systems. Have delivery teams report progress against the prioritized backlog, not against random projects.

Mistake 7: Inadequate documentation and traceability

Decisions about priority, scope, and rejection are not documented. Future stakeholders do not understand why something was rejected or why it was prioritized low. Decisions are questioned and reopened.

Fix: Document every major decision: why was this request approved, why was it rejected, why is this priority versus others? Keep decision history in the request record or a linked decision log.

Prevention: Make documentation part of your definition of done. A request is not formally approved or rejected until the decision and reasoning are documented.

Mistake 8: Missing dependency management

Request A depends on request B. If B is deferred, A cannot proceed, but no one realized the dependency. Schedules slip and rework happens.

Fix: Explicitly document dependencies in demand management. When prioritizing, consider dependencies: prioritize B before A if A depends on B. When deferring a request, check if any other requests depend on it and adjust downstream priorities.

Prevention: Make dependency documentation a required field when submitting requests. Have the portfolio review specifically check for and discuss cross-request dependencies.

Mistake 9: Poor communication

Stakeholders do not know the status of their requests. They re-submit requests because they think the first submission was lost. They are surprised when a request is rejected.

Fix: Communicate decisions: when a request is approved, when it is scheduled for delivery, when it is rejected. Set expectations for decision timelines that your governance group agrees on. Provide status updates on the priority backlog monthly.

Prevention: Establish a communication cadence. Monthly portfolio updates go to stakeholders. Individual requesters get status emails when their requests change state. Make communication proactive, not reactive.

Mistakes that hide inside a working demand process

A demand process can look healthy on the dashboard while the decisions behind it are weak. The queue is tidy, the forms are complete and the monthly review happens on time, yet the work that gets delivered is not the work that matters most. The mistakes below are harder to spot than missing intake forms, because they feel like rigour. Each one has a sign that appears in the first few review cycles, and each has a correction that is often about changing a rule rather than buying anything.

A table of mistakes, what they look like and how to correct them

Why size-based scoring quietly distorts the portfolio

Scoring models often include an effort or cost factor, and the way that factor is written decides who wins. If a large request scores well on strategic fit and a small request scores well on quick benefit, a total score can simply favor the large one because it has more points to earn. The portfolio then fills with big, slow items and the small improvements that users actually feel never reach the front. A simple fix is to review two views before the ranking is finalised: one total score, and one that compares value against effort. The conversation then turns to the trade-off, which is where it belongs.

A correction sequence for a portfolio that has drifted

When several mistakes appear together, it helps to correct them in order. Changing the scoring first, before the intake form is reworded, means the old form will still produce the old kind of request. Changing the form first means the new requests will be scored by the old rules. The sequence below avoids both problems.

1. Reread the last two cycles of decisions and list the rankings that surprised the sponsors. Those surprises point to the rule that needs fixing.
2. Reword the intake form so it asks what hurts, who is hit by it and what doing nothing costs.
3. Add the capacity check as a required step before approval, with a named owner for the capacity figure.
4. Adjust the scoring so that value and effort are both visible, and test the new view against the surprising rankings from step one.
5. Set review dates on everything currently approved, and retire items that nobody will re-confirm.
6. Send the rejection reasons and the new rules to submitters in one message, so that people understand what changed.

When not to change the rules

Some organizations change their demand rules every quarter in response to whichever sponsor complained most recently. That instability is itself a mistake, because submitters stop trusting any rule and start gaming the form. A reasonable rule of thumb is to change the criteria only after a full cycle in which the same problem appears, and to record the reason for each change. If a criterion is clearly wrong, correct it at once, but do not treat every complaint as evidence that the model has failed.

Signs the mistakes are being contained

• The largest request is not automatically the highest-ranked request.
• Every approval has a capacity note and a review date.
• Submitters rarely resubmit a rejected request without a changed problem statement.
• Benefit follow-ups appear on the portfolio record after delivery.

How often should the scoring model be reviewed?

Review it at the end of each full portfolio cycle, and whenever a sponsor shows that a ranking contradicts a documented strategic priority. Keep the review short and focused on the rules that produced the surprise, rather than reopening every criterion.

What do we do with requests that are approved but never started?

Ask the sponsor to confirm the need at the review date. If the need has gone, retire the item and record why. If the need remains but no capacity exists, move the item to a visible waiting list with its position explained, so that the sponsor understands the delay rather than discovering it later.

Should business cases be mandatory for small requests?

A full case is seldom needed for a small request. A short statement of the problem, the people affected and the expected outcome is often enough. Reserve the longer case for work that will consume significant capacity or carry material risk.

How do we stop people resubmitting rejected requests?

Resubmission is a symptom of unclear rejection. When a request is turned down, say which criterion it failed and what would change the answer. Many resubmissions stop once the submitter knows what new evidence would be needed.

A short review often shows which rule is producing the distortion.

The intake side of these rules is covered further in the request approval controls guide, and the capacity question is described in the capacity planning signals guide.

Demand prioritisation tables, fields and values to check on your instance

Demand prioritisation in ServiceNow means ranking records in the demand table, dmn_demand, before any of them is converted into delivery work such as a project. Ranking only helps if the scoring rule and the capacity check happen before approval, not after the request has been promised.

These are common out-of-box names. Check them on your own instance and release, because labels and defaults change between releases and plugins differ.

Prioritisation often goes wrong in the order of steps rather than in the formula. Rank by value for effort first, check capacity second, approve third, and set a review date on every approval. A single priority choice list is too coarse to carry all of that, so keep a separate score beside it and let the board read both. The demand management best practices page covers the surrounding process.

Example (hypothetical): a board notices a large reporting rebuild outranking five small fixes because its total score has more categories to earn points in. The board adds a value-per-effort column, reads it before ranking, and moves the small fixes up the order for the next review. The portfolio governance model shows where that review sits.

Should demand priority and demand score be the same field?

No. Priority on a task-based record is a coarse choice list that people can change by hand, while a score, where you use scoring, is calculated from criteria you define. Keep both so the board can see when a manual priority disagrees with the scored order.

Which table should hold the decision record?

Keep the decision on the demand record in dmn_demand, in work notes or a field you add for it, so it stays with the request after conversion. A project later created in pm_project can then be linked back to the reason.

What should the capacity check look at before approval?

Look at the assignment groups who would deliver the work, their committed projects in pm_project and the dates the request needs them. If those groups are already full for that period, defer the approval rather than recording it and waiting. See strategic portfolio and demand intake for the intake side.