ServiceNow Resource Management Governance Model

Resource governance comes down to a short list of questions with named owners: which initiatives get people first, how demand is balanced against the supply of skills, who approves an assignment, who watches whether allocated people are really working on the allocated project, and who settles a conflict. The sections below set out the decision forums and their cadence, the standards for allocation, utilisation and conflicts, change control for the resource configuration, ownership, monitoring, pool management and exception handling, followed by how to keep the forum from becoming a sign-off ritual.

Decision Forums

Establish a resource management committee that meets monthly or quarterly, depending on organization size and change frequency. Committee includes portfolio manager, PMO director, IT leadership, and business unit leaders. Purpose is to align on resource allocation for large initiatives and resolve resource conflicts.

Committee should make decisions on: strategic initiative staffing, cross-project resource conflicts, resource pool sizing and composition, major skill gap remediation, and resource allocation policy exceptions. For daily operational decisions, committees are too slow. Reserve committee time for strategic decisions.

Establish operational forums for day-to-day resource management. Project managers meet weekly to coordinate on resource assignments. Resource managers meet weekly to forecast availability and identify conflicts early. Escalate conflicts to resource committee if day-to-day resolution fails.

Standards for Resource Allocation

Define standards for how resource allocation works. Standard might be: when a new project is approved, resources must be allocated within an agreed time limit from the resource pool. If the pool lacks needed skills, the project is delayed or external resources are engaged. Standard prevents projects from waiting indefinitely for staffing.

Define standards for resource utilization targets. For example: billable resources should be allocated to client work within a target band the resource director sets, with significant portions for training and significant portions for internal work. Standards help balance utilization and burnout. If utilization is too high, people burn out. If too low, capacity is wasted.

Define standards for resource conflicts. If two projects need the same person, who has priority? Usually, strategic initiative has priority over operational work. High-priority customer project has priority over low-priority internal project. Document the hierarchy so conflicts are resolved consistently.

Change Control for Resource Configuration

Resource roles, skills matrices, and cost rates should not change frequently or without review. A change control process prevents accidental errors that corrupt resource planning. For example, if someone deletes a skill from the system, all resource records using that skill break. Change control prevents this.

Define what requires change control. Adding a new skill category requires approval. Removing a skill may require review of all resources using it. Changing cost rates requires finance approval and should be effective at a specified date. Changes to resource levels—hiring or headcount reduction—require resourcing committee approval.

Lightweight change control for routine changes. Updating an individual resource’s skills can be done operationally. Adding a resource to a project can be done by resource manager. Changes affecting planning or cost should go through formal change control.

Ownership and Accountability

Assign a resource director or manager who owns the resource management program. This person is accountable for establishing standards, operating governance forums, and monitoring compliance. They are the escalation point for resource conflicts.

Assign resource managers (often by function or business unit) who manage day-to-day resource allocation. They understand the resource pool, skill availability, and project demands. They recommend resource assignments and forecast future needs.

Assign project managers who manage resource allocation to their specific projects. They request resources, negotiate allocation with resource managers, and monitor resource performance on their projects.

Resource Monitoring and Review

Monitor resource utilization. Track what percentage of each resource’s time is allocated to planned work. If allocation is below target, investigate—is the resource capacity underutilized, or are demands lower than expected? Adjust planning or allocation accordingly.

Monitor skill gaps. Compare skills needed for approved initiatives against skills available in the resource pool. Identify gaps. Plan training or hiring to fill gaps. Track gap remediation progress.

Monitor resource allocation accuracy. Sample projects—do resources spend their time on allocated projects, or are they pulled to other work? If significant variance exists, improve forecasting or clarify allocation rules.

Resource Pool Management

Define what constitutes the resource pool for the organization. Are all employees in the pool, or just certain departments? Are contractors included? Are offshore resources treated the same as onshore? Clarity on pool definition prevents confusion when allocating.

Forecast resource supply. How many resources will be available next quarter? Account for planned leaves, training, and internal projects. This forecast lets the organization understand capacity constraints and plan accordingly.

Manage resource demand. Catalog all projects and initiatives requiring resources. Prioritize them. Allocate available capacity to highest-priority initiatives. Adjust timelines or scope if capacity is insufficient.

Escalation and Exception Management

Define escalation path for resource conflicts. If project managers disagree on who should work on a project, escalate to resource director. If resource manager forecasts insufficient capacity for all approved initiatives, escalate to leadership for prioritization. Escalation should be timely—do not let conflicts linger.

Define exception approval process. If a critical initiative needs a resource allocated at all available, exceeding normal utilization target, who approves? Usually resource director or leadership. Exceptions should be documented and temporary.

Track exceptions. Accumulation of exceptions indicates standards need adjustment. If many initiatives are exceptions to allocation standards, standards are probably too rigid. Conversely, if exceptions are rare, standards are appropriate.

Writing down who decides each resource question

Many governance failures in resource management are not failures of meetings. They happen because a decision was made in a corridor, the allocation was changed in the system by whoever had access, and nobody can later say who approved it. A governance model earns its place when every recurring resource decision has a named proposer, a named decider and a record. The decision rights table below is the simplest way to start, and it is worth drafting before any forum is scheduled.

Keeping an exception register that someone reads

Exceptions are where governance quietly stops working. A critical project needs a specialist beyond the standard, a manager approves it verbally, and six months later the specialist is still stretched and the standard is still listed as policy. An exception register fixes this only if it is reviewed. Each entry should carry the person or role affected, the reason, the approver, the date it was granted and the date it lapses. When an entry reaches its lapse date without renewal, the allocation should revert automatically or the register should show it as overdue.

The register is also a diagnostic. If the same standard is excepted again and again, the standard is probably wrong for the work the organization now does. Bring that pattern to the governance forum as a proposal to change the standard, not as a list of individuals who need permission.

Running the forum without it becoming a sign-off ritual

A forum that only ratifies decisions already made elsewhere wastes everyone’s time, and people stop preparing for it. A short agenda with three standing items keeps it useful: decisions waiting for a ruling, exceptions due to lapse, and the current conflicts that the operational forum could not resolve. Papers should arrive before the meeting with the two competing options written out, so the decision is made on the facts rather than on whoever spoke last.

1. Confirm which decisions in the decision rights table are on the agenda and which were already settled by the operational forum.
2. Review the exception register for lapsing items and decide renew, revert or retire for each one.
3. Take each open conflict in turn, record the chosen option and the reason in one sentence, and name who will tell the affected project leads.
4. Circulate the decisions within a day, so the allocation changes can be made in the system before the next weekly review.

Signs the governance is too heavy or too thin

A model that is too heavy shows up as decisions queuing for weeks, project leads routing around the process, and managers who keep a private list of exceptions. A model that is too thin shows up as conflicting allocations that surface only when a project misses a date, and as configuration changes that nobody can trace. The fix for heavy governance is often to push routine changes down to the operational forum with clearer limits. The fix for thin governance is often to add the change control step for the few items that affect planning or cost, not to add meetings.

Follow-on questions about running resource governance

Who should chair the resource governance forum?

Someone with authority over both the portfolio and the people, usually the resource director or a senior portfolio leader. A chair from only one side tends to favor that side’s projects. The chair does not need to make every decision personally, but must be able to break ties within the forum’s agreed limits.

Should the exception register be visible to project leads?

Yes, in summary form. Project leads who can see that a colleague’s project holds a time-limited exception are less likely to press for their own. Keep the register’s detail, such as the reasons and approvers, visible to the forum members only if the organization’s employment practices require it.

How do we govern a pool that includes offshore or partner resources?

Use the same decision rights for allocation, but add review points for contract terms and time zone coverage, which the operational forum rarely sees. Partner capacity should appear in the exception register when it is used beyond what the agreement anticipated.

What if the portfolio priorities change every quarter?

Then the governance is working as a signal, but the priorities are unstable. Ask the forum to record how many allocation changes each priority shift caused. That count is often the strongest argument for a slower, clearer prioritization process upstream.

Get an outside view on your governance design

If the decision rights in your organization are unclear or the forum has stopped being useful, it helps to map the decisions first, before any configuration changes are made. Map the people behind each row using the roles and RACI for resource management, and check how the decisions are enforced in security and access design. The common resource management mistakes guide covers overallocation and other common problems.