ServiceNow Demand Management for Technology and Software

Demand Management in a technology company is about internal competition for engineering capacity: product, platform, security and compliance requests all land on the same teams. This page covers how to balance the portfolio across feature work, infrastructure, security and technical debt, how to match demand to realistic capacity, which prioritisation criteria make trade-offs defensible, how to track whether approved demand delivered value, and the intake rules that work when one team serves several kinds of requester.

Demand Intake and Portfolio Balance

Technology teams must balance competing demand types: new feature development, infrastructure maintenance, security work, and technical debt reduction. Demand Management should track portfolio mix: what percentage of capacity goes to each category. Over time, monitoring this mix prevents scenarios where technical debt accumulates until infrastructure becomes fragile.

Intake processes should make demand visible: what work is currently requested, what is scheduled, what is backlog. Visibility helps stakeholders understand why their request isn’t scheduled immediately and when it might be addressed.

Capacity Planning and Resource Allocation

Technology Demand Management must match demand against available capacity. How many engineers are available for new work after accounting for operational work, on-call duties, and existing commitments? Capacity planning should be realistic rather than optimistic, avoiding promises that cannot be kept.

Resource allocation decisions often involve trade-offs: investing in one feature means another feature is delayed. Making these trade-offs explicit and defensible prevents frustration when promised work doesn’t materialize.

Tracking Demand Outcomes and Value Delivery

Technology companies should track whether completed work delivers expected value. Did a feature delivered actually get used? Did a performance optimization reduce customer complaints? Did technical debt reduction prevent predicted failures? Tracking outcomes helps organizations make better prioritization decisions.

Some organizations implement post-launch reviews where delivered work is evaluated against original predictions. This feedback improves future prioritization accuracy.

Resource Forecasting and Capacity Planning

Demand management should project future resource needs based on pipeline of approved work. If current demand exceeds available capacity, organizations should plan capacity increases: hiring, training, or tool investments. Capacity planning should be data-driven: based on actual demand trends and project complexity, not optimistic assumptions.

Resource allocation decisions should account for team capability: are specific engineers required for specific types of work, or is capacity interchangeable. Complex technical work may require senior engineers; routine operations may be handled by junior staff. Demand prioritization should account for these capability requirements.

Prioritization Criteria and Trade-off Analysis

Demand management should use consistent criteria prioritizing work: strategic alignment with business goals, customer impact if work is deferred, risk reduction, technical debt payoff, and resource requirements. Different organizations weight these criteria differently: startup companies prioritize customer impact and strategic alignment, mature companies may prioritize technical debt and risk reduction. Clear criteria make prioritization defensible and repeatable.

Trade-off analysis should be explicit: completing initiative A means initiative B is delayed, or completing both requires hiring additional staff. Leadership should understand trade-offs and make informed decisions about priorities. Regular review of prioritization results (do completed initiatives deliver expected value) improves future prioritization accuracy.

Visibility and Communication

Demand management systems should provide visibility: what work is planned, what is scheduled, what is backlog. Teams can see whether their requested work has been accepted, scheduled, or remains in backlog. Regular communication about demand status keeps stakeholders informed and sets expectations about when work will be addressed.

Managing Demand Across Development and Operations

Technology organizations typically struggle with the balance between new feature development and operational stability. Development teams want capacity for innovation; operations teams need resources for incident response and maintenance. Demand management should explicitly allocate capacity to both.

Organizations should define target portfolio mix: name a share for each of new feature development, technical debt reduction, and operational support, and record who agreed it. Monitor actual allocation against target. If too much capacity flows to operational work, it signals that operational processes are inefficient or incident frequency is too high—issues that should be addressed separately rather than accepted as permanent constraints.

Forecasting demand trends helps organizations plan staffing and resource allocation. If demand for infrastructure work is growing faster than demand for new features, that signals the need for infrastructure investments or team skill development. If demand for security work is increasing, it signals either growing security concerns or increasing regulatory requirements that should inform business strategy.

Intake rules for engineering, security and compliance requests that compete for one team

In a software company, demand rarely arrives in one orderly stream. Product managers want features, security finds a flaw that needs a code change, compliance adds an obligation with a date attached, and engineers want to pay down a piece of the platform that slows every release. All of these draw on the same people. Demand management decides, in one place and with written reasons, which of them the team takes on and in what order.

The intake form is the easy part. The harder decision is what each source of demand is allowed to claim. A security finding that exposes customer data is not the same kind of request as a feature asking for a new export format, and a scoring model that treats them alike will consistently under-fund the security work, because feature requesters are more numerous and more visible.

Setting an intake owner and a scoring question for each source

The scoring questions are written as questions on purpose. A number in a scoring sheet hides the judgment behind it, and the people who challenge a decision need to see the judgment. The declining reasons matter as much as the acceptances, because they are what stops the same request returning every quarter.

A sequence for running intake without it becoming a gate

The sequence below is designed so that demand management improves planning rather than delaying urgent work. Urgent security patches are the clearest case. They should not wait for a scoring cycle, and the demand management process should say so explicitly.

1. Create one intake with a demand type field, so every source fills in the same record and the team can compare like with like.
2. Agree the scoring questions with the intake owners before the first cycle, and write them where requesters can read them.
3. Reserve capacity by demand type before ranking individual items, so security and compliance work is not negotiated again every planning cycle.
4. Publish each declined item with its reason, and keep the record so the same request can be recognized when it returns.
5. Review completed items against the question each one was accepted for, and note whether the outcome matched the answer given at intake.

Where demand management goes wrong in software companies

A frequent failure is ranking by how many people asked. Requests that come from the most senior or most connected stakeholders attract the most attention, and quiet, important work such as a dependency upgrade never reaches the top of anyone’s list. The second is reserving no capacity for security work, so that every security item competes with features and loses in most cycles. The third is declining without a reason. Requesters who receive no explanation resubmit, and the intake fills with duplicates that consume the time demand management was meant to save.

A less visible failure is treating a compliance obligation as if it were a feature. An obligation has a deadline and a consequence for missing it. Scoring it against features on value alone can push it below the line, and the team discovers the omission at the point where the obligation has to be evidenced.

When demand management is the wrong tool

It is the wrong tool for an active security incident, a customer outage or a regulatory notice with a short window. Those have their own routes, and placing them behind an intake queue is a way of making the process look busy while the real risk waits. Demand management should be a planning mechanism for work that can be scheduled, not a permission system for work that cannot.

How to tell the intake is doing its job

Look for three things. Declined items are rarely resubmitted without new information. Security and compliance items are scheduled as a matter of course rather than negotiated afresh each time. The team can explain, for any item in the backlog, the reason it was accepted and the question it was meant to answer. If the team cannot do the third, the scoring questions are not being used.

What to do when a request is both a feature and a risk reduction

Split it. A request that adds a capability and also removes a weakness usually contains two pieces of work with different owners and different urgency. Scoring them separately prevents the risk reduction from being approved only because the feature is attractive, and it prevents the feature from being declined because the risk part looks dull.

Should engineering be allowed to submit its own demand?

Engineers should file that demand through the same intake as every other source. Engineers often know which debt is causing incidents better than anyone else, but their requests are most credible when they cite the incidents or delivery delays involved. That evidence is what makes the request comparable with a feature.

Does demand management replace the product roadmap?

No. The roadmap says what the business wants to achieve, and demand management says how the team’s capacity is spent on the requests that serve it. A roadmap item with no demand record has no capacity behind it, and a demand record with no roadmap link is usually a request nobody has agreed to fund.

Next step

Grouping the open requests by source is a practical first step. Once grouped, the scoring questions for each source can be agreed against the items already waiting in the queue.

ServiceNow demand management tables, fields and scoring values for engineering teams

In ServiceNow, a demand is a record in the dmn_demand table that holds a request until someone decides whether it becomes a project or is declined. For a technology team the deciding fact is that scoring questions are commonly held as assessment records, so they can be changed separately from the demand record.

The names below are common out-of-box values. Check them on your own instance and release, because labels and defaults change between releases.

If your instance has no field separating feature, security, compliance, technical debt and platform requests, add a mandatory choice field to the demand form so the capacity split can be reported from the table.

Example (hypothetical): a security lead receives a finding that needs a code change and opens a demand for it. The reviewer answers one scoring question, how long the finding can stay open before a customer could be affected, and the answer is saved as an assessment instance against the demand. The fix fits work already planned, so the demand is closed without a new project, with that reason written on the record.

Which table stores a demand, and what does it extend?

A demand is stored in dmn_demand, which extends the Task table. Assignment, work notes and approvals therefore behave as they do on other task records.

Where do the scoring questions for a demand live?

In a typical setup, scoring questions are defined as assessment metric types, and each reviewer’s answers are saved as an assessment instance. Agree the wording before the first cycle, because editing a question mid-cycle makes earlier scores hard to compare.

What usually happens to a demand after it is approved?

Approved work is commonly turned into a project record in pm_project, often with a reference back to the demand it came from. Conversion options and field names differ by release and plugins, so check what your instance offers. See demand management best practices.

More detail is in the demand management guides and project portfolio management. For help setting up intake, see strategic portfolio and demand intake.