ServiceNow Demand Management Requirements Workshop Questions

This page sets out the questions a business analyst should put to an organisation before configuring demand management, covering intake, demand types, prioritisation, capacity planning and governance, and how the answers become testable requirement statements.

Demand Intake Questions

How do demands currently enter your organization? Through a portal, email, request form, direct conversation? Who can submit demands and who cannot? Are demands submitted by individuals or departments? These answers determine intake workflow design. If demands come through email, you need email integration or a process to import them. If all demands come through a formal request process, the intake interface is simpler.

Who approves or accepts demands before they enter your pipeline? Many organizations have intake reviews where submitted demands are screened for completeness and alignment with business strategy. This review is a critical gate; poor intake process creates poor prioritization later.

What information must be captured when a demand is submitted? Standard information includes business justification, department, priority request and resource estimate. Different demand types may need different information (a process improvement demand needs different information than a new capability demand). Document the required fields for each demand type.

Warning sign: If every demand gets high priority, your intake process is not filtering or prioritizing. If intake consistently rejects demands due to incomplete information, your intake form is not clear enough.

Demand Categorization and Typing

What types of demands does your organization receive? Common categories are new capabilities, enhancements to existing functionality, process improvements, maintenance and fixes. Some organizations further divide by domain (applications, infrastructure, platforms). Accurate categorization enables better prioritization; different demand types have different selection criteria.

Do some demands require different prioritization logic than others? For example, regulatory compliance demands may have automatic high priority regardless of business impact. Maintenance demands may have different resource allocation than enhancements. Design categorization to enable accurate prioritization.

What information distinguishes one demand type from another? A new capability demand needs business case and expected value. A process improvement demand needs current state process, improvement described and expected benefits. A maintenance demand needs system impacted and problem description. Each type has different required information.

Warning sign: Demands that should not be in the queue at all (not actionable, outside scope) keep appearing. This indicates categorization and intake filtering is not working.

Prioritization Criteria

What factors matter when prioritizing? Business value is usually important (revenue impact, cost savings, customer satisfaction impact). Strategic alignment matters (does this demand support business goals). Risk matters (does it reduce risk). Resource availability matters (can we do this with current capacity). Dependencies matter (does this enable other work to proceed).

How much weight does each factor get? If business value is the only factor, demands that align with strategy but have less immediate value get deprioritized. If strategic alignment is heavily weighted, business value becomes secondary. Document the trade-offs you are making.

Are some demands always high priority? Regulatory compliance, security issues and critical fixes often bypass normal prioritization. Document these exceptions explicitly. If the exceptions are too broad, you do not have real prioritization (everything is high priority, so nothing is).

Warning sign: Frequently, demands that were deprioritized get reprioritized or pushed through outside the process. This indicates your prioritization criteria do not match reality or stakeholders do not trust the process.

Portfolio Capacity Planning

How much demand capacity do you have? This is typically measured in team-months or story points available per quarter. If you do not know your capacity, you cannot plan realistically. Calculate total available capacity minus infrastructure maintenance, support and mandatory work. What is left is discretionary capacity for new demands.

Do you size demands before prioritization or after? Pre-sizing allows prioritization based on effort and value trade-off. Post-sizing creates surprises when you discover a high-priority item is enormous. Sizing estimates can be rough but they must exist.

How many quarters ahead do you plan? Planning a few quarters ahead allows teams to staff up or manage capacity thoughtfully. Planning far ahead is usually not realistic; too much changes. Planning only a short time ahead creates constant crisis.

Warning sign: Demands consistently exceed available capacity leading to perpetual backlog growth. This indicates either incoming demand is being accepted that should not be, or capacity planning is not realistic.

Governance and Decision Rights

Who makes prioritization decisions? A governance committee typically evaluates demands against prioritization criteria. This committee includes representation from business (what will drive value), IT operations (what is realistic to deliver), and executive leadership (strategic perspective).

How frequently do you revisit priorities? Monthly review is typical. At each review, evaluate recent changes: new demands submitted, high-risk items, completion status. Reprioritize based on current information. This discipline prevents the backlog from becoming stale.

When can priorities change mid-quarter? If high-risk issues emerge or critical demands arrive, they may be inserted into the current plan. Define what qualifies as “critical” to prevent constant reprioritization.

Warning sign: Priorities change every week or stakeholders frequently complain they were not consulted on prioritization. This indicates governance process needs refinement or communication.

Resource Allocation and Sequencing

How do you allocate people to demands? First-in-first-out, by priority, by skills, by team affiliation? Most organizations use priority with consideration for team capacity. A high-priority demand that requires a specialist waits for the specialist to be available.

Do dependencies between demands affect sequencing? Demand A must be done before Demand B. If A is lower priority but B depends on it, you may need to resequence. Identify dependencies early in requirement gathering.

How do you handle competing demands from different business units? Without strong governance, each unit pushes its priorities and conflicts emerge. Establish criteria that favor some units or types of work fairly.

Warning sign: Frequently, demands begin but are not completed because resources are pulled to higher priority work. This indicates either too much demand in the pipeline or resource allocation is not stable enough for planning.

Run the workshop to produce statements, not a list of answers

A requirements workshop for demand management often ends with a full page of answers and no agreed requirements. The participants said what they think, the note-taker wrote it down, and nobody converted it into something the build team can test. The question list in the workshop is only the input. The output has to be a set of short requirement statements, each with an owner, a rule and a way to prove it works. Plan the session backwards from that output: decide what a finished requirement looks like before the first question is asked.

The reader here is the business analyst or demand lead who has been asked to run the sessions and turn them into a usable specification. The aim is to leave the room with fewer, sharper statements than the discussion produced, and a clear list of the points that were not resolved.

Who to invite, and what each person must bring

The mix of people determines whether the answers will hold later. A session with only the demand desk can produce an intake that the delivery teams reject. A session with only senior sponsors can produce rules that nobody on the front line can follow. The table sets out a workable mix, with the input each group should bring so the session does not start from zero.

Ask each group to send its input two working days ahead. A session that begins with people reading a document for the first time spends its time on orientation and leaves no room for the difficult decisions.

Turning answers into requirement statements

Every answer in the room should pass through the same conversion before the session closes. The conversion is simple, but it is where most workshops lose their value.

1. Write the answer as a single sentence starting with the actor, such as the demand desk or the sponsor, and the action they take.
2. Replace any adjective that cannot be tested. Words such as timely, strategic or appropriate need a rule behind them, or they should be removed.
3. Attach one owner to the statement. If two groups claim it, record the disagreement as an open item rather than a shared requirement.
4. Write one acceptance check that a tester could run against the built process, such as submitting an incomplete request and confirming it is held.
5. Mark the statement as agreed, agreed with a condition, or open. Only agreed statements go to the build backlog.

Handling disagreement in the room

Disagreement is useful in a requirements workshop, provided it is recorded rather than settled by whoever speaks loudest. When two groups give incompatible answers, do not average them. Write both positions into the open list, name the decision owner who must resolve the conflict, and set a date for the answer. A session that finishes with a long open list has been productive, because the open list is the agenda for the next decision meeting.

Watch for answers that are really about the tool rather than the process. A participant who asks for a particular screen layout is often describing a need that the process does not yet state. Ask what decision the screen would support, and capture the decision instead of the layout.

Questions a workshop facilitator should be ready for

How long should the sessions run?

Short enough that the participants stay engaged, long enough to finish the conversion step. Plan separate sessions for intake, decisions and reporting rather than one long session, because each draws a different group and a different set of decisions.

Should requirements be signed off in the same session?

Agreed statements can be confirmed in the room. Conditional and open items should not be. Give them a named owner and a return date, and confirm them in a short follow-up that repeats the wording exactly, so that nobody later remembers the requirement differently.

What if a senior sponsor refuses to attend?

Request a named delegate with authority to decide on their behalf for the topics in scope. If no delegate exists, the requirements that depend on that sponsor should be marked open, because they cannot be agreed without the person who will be held to them.

How do we keep the requirements from growing after the workshop?

Route every new requirement through the same conversion and the same owner. A requirement that arrives by email without an owner or an acceptance check is not yet a requirement, and it should wait in the open list until it has both.

Related guides: ServiceNow Demand Management Testing and Acceptance Checklist and ServiceNow Demand Management: Roles, Responsibilities and RACI.