ServiceNow Resource Management Requirements Workshop Questions

This page is a question set for a requirements workshop on ServiceNow Resource Management. It asks how a team plans, allocates and reports on people and skills, so that the answers can become configuration decisions before any build starts.

Resource Planning Strategy and Governance

Start with how your organization plans resource allocation. Does resource planning happen annually or continuously? Is planning centralized (one team allocates resources across the enterprise) or distributed (each department plans its own resources)? Do you track resource utilization (how much are people working?) or just headcount (how many people do we have)? Do you have a resource governance process—how are resource conflicts resolved when two projects want the same person?

Questions to ask: Who owns resource planning in your organization? Is it your CFO (budgeting perspective), CIO (IT capacity perspective), PMO (project demand perspective) or HR (employee perspective)? How do you balance project demand against available resources? When resources are overallocated, who decides what work gets deprioritized? Do you track resource utilization or just headcount? Answers shape ServiceNow configuration—planning processes, escalation paths, and reporting structure.

Project Portfolio and Demand Forecasting

Resource Management connects to project portfolio management. How many projects does your organization run? How far in advance do you know about future projects? Do projects have stable plans or do they change frequently? How do you forecast resource demand—do you have confidence in project estimates of resource needs?

Questions to ask: What is your typical project pipeline looking forward? How does demand vary by resource type (developers, infrastructure, business analysts)? How stable are project plans—are estimates reliable or do they change frequently? Do you have resource bottlenecks (certain roles are scarce)? How do you currently forecast demand—do you use tools or spreadsheets? Answers shape demand planning and forecasting configuration in Resource Management.

Resource Types and Skills Tracking

Resource Management needs to track not just how many people you have, but what skills they have. Do you track only job title (developer, project manager) or do you track specific skills (Python, Java, testing automation, business analysis)? Do you know which people are trained or have special qualifications? How detailed do you want skills tracking to be—just enough to allocate people to projects, or detailed enough to identify training gaps?

Questions to ask: What skills matter most for your organization? How detailed should skills tracking be? Who maintains skills data—HR when employees are hired, or project managers as people work on projects? How do you validate skills—certification, assessment, or manager judgment? Are there critical roles where you want detailed skill tracking (senior architects, security specialists)? Answers shape skills model configuration and data quality requirements.

Capacity Planning and Utilization Targets

Organizations typically have utilization targets—what percentage of time should people spend on billable or project work versus non-billable work (meetings, training, administrative)? For example, if a person works 40 hours per week, they might be expected to allocate most of their time to projects, leaving some hours for administration, training and overhead.

Questions to ask: What’s your target utilization for different resource types? Is utilization different for different departments (some departments might have higher targets than others)? How do you measure actual utilization—do people log time? Do you want to track utilization in Resource Management or just capacity planning? What’s acceptable variance from target when demand is high? Answers shape capacity planning and reporting configuration.

Resource Conflicts and Allocation Decisions

Resource conflicts occur when demand exceeds supply—two projects want the same person. How does your organization resolve conflicts? Does the PMO decide which project gets priority? Do project managers negotiate? Do resource owners allocate their people? Is there an escalation path for unresolved conflicts?

Questions to ask: When resources are overallocated, who makes allocation decisions? Are there clear priority criteria (strategic projects get priority, revenue-generating projects get priority)? How quickly must conflicts be resolved? Do you have a resource governance forum or process for this? Are there critical resources that should never be overallocated (key architects, security specialists)? Answers shape workflow and escalation configuration in Resource Management.

Contractor and External Resource Management

Many organizations use contractors, consultants and outsourced resources in addition to employees. Does Resource Management need to track contractors? Do they have the same allocation process as employees? Are there compliance or contract management requirements for external resources?

Questions to ask: What percentage of your work is done by contractors versus employees? Do you want to track contractors in Resource Management or in a separate system? Are there contract requirements—do you need to know when contractor contracts expire? Are there compliance requirements (staffing ratios, contractor approval process)? For audit purposes, do you need to track why contractors were used instead of permanent staff? Answers shape whether to include external resources in Resource Management or keep separate.

Reporting and Optimization

Resource Management enables reporting and optimization decisions. Can you report on resource utilization by department, by project, by resource type? Can you identify bottlenecks (overallocated roles, underutilized capacity)? Can you forecast whether your current resources can deliver planned projects? Can you show ROI of resource investment (do certain resources contribute more to revenue than others)?

Questions to ask: What reports do leadership need? Typical reports include utilization by department, project resource costs, resource forecast versus plan, and capacity bottlenecks. What decisions are made based on reports? (hiring decisions, make/buy decisions, project prioritization?) How frequently are reports needed (weekly, monthly, quarterly)? Do you need historical reporting to show trends? Answers shape reporting configuration and data requirements.

Who needs to be in the room, and who should be interviewed separately

A requirements workshop for resource management fails in two common ways. Either the room is full of people who manage capacity but never see the requests, or it is full of requesters who have never seen how a pool is actually planned. The people who decide allocation, the people who forecast it and the people who raise demand need to hear each other’s constraints in the same session. Finance and HR should join for the part that concerns cost and records, and they can often join for that one part only.

Some topics produce more candor in a one-to-one interview than in a group. Questions about how often a manager overrides the plan, or how a contractor is brought in when the permanent pool is full, tend to get guarded answers in front of peers. Run those as short separate interviews and bring the themes back to the workshop without attributing them.

Turning the answers into configuration decisions

A workshop is only useful if its answers come out as decisions that someone can build against. Each area of the discussion should produce a specific artifact, and the table is a way to check that every section of the workshop ends with one.

Recognizing weak answers before they reach the design

Some answers look complete and still leave the design unsafe. A few patterns deserve a follow-up question on the spot rather than a note for later. An answer that says the portfolio is always prioritized, with no example of a deferred project, often means the prioritization is informal. An answer that says capacity is tracked in a spreadsheet, with no named owner for the spreadsheet, suggests the data will be stale at launch. And a reply that every skill is critical tends to mean the skills taxonomy has not been tested against real requests.

1. Ask for one recent example for every process described as standard.
2. Ask who would have to be told if the answer changed next quarter.
3. Record any answer that depends on a person as a dependency, with that person’s name.
4. Record each unanswered point on the open list, naming an owner and a resolution date.

When a workshop is the wrong first step

If the organization has no written portfolio priorities and no agreed resource owner, a requirements workshop will often generate disagreement that the room cannot resolve. In that case, the first step is a short decision session on priorities and ownership, and the requirements workshop comes after. Running the workshop too early turns into a list of wishes that the platform will then be asked to satisfy.

Follow-on questions about running the workshop

How long should the pre-work take for attendees?

Keep it to a short data request: a list of current projects, the roles they draw on, and a sample of recent resource requests. Attendees who arrive with real examples give far better answers than those asked to recall them on the spot.

Should the workshop cover reporting before the allocation process?

No. Reporting requirements depend on which decisions the process supports, so define the allocation and approval steps first. Asking leaders for their dashboard wishes too early produces a long list of charts that nobody is responsible for keeping accurate.

What do we do with a requirement that conflicts with the current practice?

Record both positions and the reason for each, then decide which one the platform will support, with the owner of that decision named. Quietly dropping the conflicting requirement is a common way a rollout later meets resistance from the people it excluded.

How do we know the workshop has finished its job?

When each area in the table above has an artifact, every open item has an owner, and the people who attended can describe the same allocation process in the same words. If they cannot, the workshop has produced agreement on topics but not on the design.

Planning the requirements sessions

If you are preparing to scope resource management, the sessions can be planned so that the answers turn into a configuration brief. Naming the people for each session is easier with the roles and RACI guide, and the enterprise use cases give the discussion concrete scenarios to test against. Decisions about who owns each allocation rule belong in the governance model, and cost questions raised in the room can be sized with the licensing and cost guide.