ServiceNow Demand Management Governance Model

Defining Your Demand Management Governance Structure

Demand Management governance establishes who makes decisions about work priorities, who has authority to approve new requests, what standards requests must meet, and how often priorities are reviewed. Without clear governance, organizations end up with unclear priorities, conflicting decisions, and stakeholders confused about what is being worked on.

The core governance structure includes a demand review board (approves new requests, prioritizes work), standards council (defines request standards and quality criteria), and portfolio management team (tracks demand patterns and capacity). Some organizations combine these into one forum; others keep them separate.

Demand Review Board

The board meets weekly to review new requests and approve prioritized work. Membership includes representatives from business units submitting requests, IT leadership responsible for capacity, and finance (if requests affect budget). The board has authority to approve or deny requests.

Board decision criteria: strategic alignment (does this support our strategy?), business value (what is the payback or customer impact?), resource fit (do we have capacity?), and risk (can we execute this with acceptable risk?). Make criteria explicit so requesters know what matters.

Approval workflow: new requests are logged in ServiceNow with required information (business objective, resource estimate, timeline, business case). The demand board reviews and either approves, defers, or rejects the request. Rejected requests go back to the requester with feedback.

Demand Standards and Quality Criteria

Define minimum standards for requests: every request must include a business objective, resource estimate, timeline, and expected outcome. Requests without these details are not considered. This prevents vague or incomplete requests from clogging the queue.

Establish quality gates: requests must meet minimum criteria before being presented to the demand board. A demand coordinator pre-screens requests, asking clarifying questions if needed. Only complete requests go to the board for prioritization.

Define request types: standard operational requests (maintenance, fixes), enhancements (new features, improvements), and strategic initiatives (multi-phase major projects). Each type follows a different approval path. Strategic initiatives need executive approval; operational requests might be pre-approved if they fit within capacity.

Change Control for Configurations

When approved work requires configuration changes (adding fields, changing workflows, integrating systems), define a change control process. A change control board reviews proposed changes, validates they do not conflict with other work, and schedules the change for implementation.

Change control decisions include: approve and schedule (implement immediately after testing), defer (schedule for a later batch), reject (found to be infeasible or lower value than expected). Clear decision criteria prevent decisions from being arbitrary.

Track change impact: what will change when this configuration is implemented? Who will be affected? What training is needed? Change control that only looks at technical feasibility but ignores impact often leads to failed implementations.

Ownership and Accountability

Assign clear ownership: the demand review board owns the overall demand prioritization strategy and makes approval decisions. The standards council owns quality criteria and request standards. A demand manager is responsible for maintaining the demand queue, managing the board meetings, and tracking metrics.

Business unit leaders own submitting clear requests on behalf of their organizations. They are responsible for providing the information the board needs to make decisions.

IT leadership owns capacity planning: realistic assessment of available capacity to deliver approved work. Padding estimates or under-reporting capacity leads to overcommitment and delivery failures.

Review Cycles and Feedback

Conduct quarterly demand reviews: analyze request trends (are requests increasing or decreasing?), approval rate (what fraction are approved?), cycle time (how long from request to decision?), and delivery success (are approved requests completed as planned?).

Use metrics to identify improvements: if approval cycle time is longer than your target, requests wait too long. If delivery success rate is consistently low, the organization is overcommitting. Adjust governance based on metrics.

Annual review: does the governance model still fit the organization’s needs? Are forums meeting regularly and making decisions, or have they become rubber stamps? Are requesters satisfied with the process? Adjust governance annually based on feedback.

Escalation and Exception Handling

Define escalation paths: if a requestor disagrees with a demand board decision, who can they escalate to? Usually the CFO or COO. Escalations should be rare; if they are common, the board’s decision criteria may be unclear or inconsistent.

Handle emergency requests: what happens if a critical issue arises mid-quarter (e.g., security incident, customer crisis)? Emergency requests can bypass the normal queue if approved by the executive sponsor. But emergency overuse undermines governance, so limit and track emergency approvals.

Start with a decision rights list, not a committee chart

Many governance designs begin with the forums: a board here, a council there, a portfolio team beside them. The better starting point is a list of the decisions the organization actually makes about demand, one per line. Typical lines include accepting a request into the queue, ranking it against others, releasing capacity to it, changing its scope after approval, stopping work that is already running and deciding whether an exception to the rules is justified. Once the list exists, the forums fall out of it. Each decision needs exactly one accountable owner, a named group that must be consulted, and a written place where the outcome is recorded.

A head of IT or transformation who is designing a new governance arrangement, or reforming one that has become a rubber stamp, often inherits a set of forums whose purpose nobody can state clearly, and needs a method for deciding which of them to keep.

A decision rights table for demand

The table below is a starting structure. Fill the columns for your own organization and resist the temptation to copy the owner names from a template. The aim is to surface the places where two groups believe they hold the same decision, or where nobody does.

The row that often causes trouble is the exception. When exceptions are granted by the whole forum, nobody feels personally responsible for the precedent they set. Naming one executive, with a required justification and an expiry, keeps the exception rare and reviewable.

Writing the governance charter in order

A charter that gets used is short, specific and written in the order people will need it. Work through these steps with the people who will actually sit on each forum.

1. Write the decision rights list from the table above and agree it with the executive sponsor before naming any forum.
2. Assign each decision one accountable owner. Where two names come up, pick one and move the other to the consulted column.
3. For each forum, state which decisions it makes, how often it meets and what quorum it needs to decide.
4. Define what a forum is not allowed to do. A portfolio forum that also sets technical standards has drifted outside its remit.
5. Set the escalation route for disagreements, including the point at which a decision moves to an executive.
6. Publish the charter, then test it on one real decision before the first full cycle, to find where the wording does not match practice.

When a single forum is the better answer

Separate forums are not automatically better. In an organization with a small number of demands each quarter, one forum that accepts, ranks and releases capacity can be clearer than three bodies that each see part of the picture. The test is whether the same people would reach a decision in the same place without the handoffs. If they would, merge the forums and keep the decision rights list as the check that nothing has been lost.

Separate forums earn their place when the decisions carry different risks. Funding a stream of routine work and approving a large change to a regulated process should not sit in the same meeting with the same quorum, because the second decision needs people the first does not.

Keeping the governance honest over time

Governance decays in a predictable way. Forums keep meeting after they stop deciding, papers are circulated with the decision already made, and the same exceptions are granted every quarter under a different name. Two checks catch much of this, and the troubleshooting guide is a useful companion when either check fails. First, compare the number of decisions each forum recorded in the last period with the number it was scheduled to make. Second, sample the recorded decisions and ask whether the stated criteria explain the outcome. If they do not, the criteria are decorative and the real decisions are being made somewhere else.

Questions governance designers ask

Who should chair the portfolio forum?

A chair who can decline a senior sponsor and still keep the delivery teams’ trust. Chairs drawn only from the business tend to favor requests with the loudest sponsors, and chairs drawn only from IT tend to favor requests that are easy to deliver. Look for a person with a foot in both camps and a mandate that the executive sponsor has put in writing.

How do we stop a forum from re-opening decisions it has already made?

Give every decision a status and a date, and state that a closed decision can only be reopened on new evidence that the decision record names. Without this rule, each change of sponsor restarts the debate.

Should the finance function have a vote?

Finance should have a defined role rather than a vote. Its job is to confirm the funding basis of a decision and to flag when a request changes the cost picture. A vote tends to make finance responsible for outcomes it cannot control, which weakens its ability to challenge.

What do we do when two forums disagree?

The charter should name the tie-break. Often that is the executive sponsor who owns the portfolio budget. If the answer is always to escalate, the forums are not defined tightly enough and the charter needs another pass.

Next step for the governance design

The companion page on roles, responsibilities and RACI shows how the same decisions translate into named people and their responsibilities inside the tool.