ServiceNow Demand Management: Roles, Responsibilities and RACI

Key Roles in Demand Management

Product Manager or Business Owner submits new demand: new products, new features, business process improvements. They provide business justification: what problem does this demand solve? What value will it deliver? What is the business priority? They own success and advocate for investment.

Portfolio Manager owns the portfolio of active work (projects, initiatives, operational tasks). They assess new demands against strategic priorities and resource capacity. They recommend which demands should be accepted, which should be deferred and which should be declined. They are accountable for portfolio balance: ensuring that the mix of projects delivers strategic value within resource and budget constraints.

Demand Management Office (or PMO) coordinates the demand intake process: collecting demand submissions, facilitating reviews, documenting decisions. They ensure consistent process and transparent decision-making.

Finance Manager ensures that demands are affordable. They review budget impact and recommend which demands can be funded given available budget. They highlight when accepting one demand requires declining another due to budget constraints.

Resource Manager ensures that resource capacity exists to deliver accepted demand. They assess skill requirements, team capacity and availability. They highlight resource conflicts: if two high-priority projects need the same team, they cannot both be started immediately.

Executive Steering Committee (CIO, VP of Operations, VP of Finance) decides on strategic prioritization. They approve which demands are accepted into the portfolio and authorize investment.

RACI Matrix for Demand Management

Task: Collect new demand submissions. Responsible: Business Owner or Product Manager. Accountable: Demand Management Office. Consulted: Portfolio Manager. Informed: Executive Steering Committee.

Task: Assess demand against strategic priorities. Responsible: Portfolio Manager. Accountable: PMO Director. Consulted: Finance Manager, Resource Manager. Informed: Business Owner, Executive Committee.

Task: Assess budget impact of demand. Responsible: Finance Manager. Accountable: Finance Director. Consulted: Portfolio Manager. Informed: Business Owner, Resource Manager.

Task: Assess resource capacity needed. Responsible: Resource Manager. Accountable: Operations Manager. Consulted: Portfolio Manager, Finance Manager. Informed: Business Owner, Project Manager.

Task: Prioritize demands into portfolio. Responsible: Portfolio Manager. Accountable: CIO or VP Operations. Consulted: Finance Manager, Resource Manager. Informed: Business Owners, Project Managers.

Task: Make final prioritization decision. Responsible: Executive Steering Committee. Accountable: CIO. Consulted: Portfolio Manager. Informed: all Business Owners, PMO.

Task: Authorize resource allocation. Responsible: Operations Manager or VP Operations. Accountable: CIO. Consulted: Finance Manager. Informed: Project Managers, Resource Manager.

Demand Assessment and Prioritization Criteria

Each demand is assessed against criteria: strategic alignment (does it advance stated business objectives?), business value (what is the return on investment?), resource requirements (what skills and effort are needed?), timeline urgency (when is this needed?), risk (what could go wrong?). Score each demand on a consistent scale (1-5, with 5 being best) for each criterion. Use a portfolio scorecard in ServiceNow to calculate overall score. Higher-scoring demands are prioritized higher in the portfolio.

Acceptance and Decline Decision Process

Portfolio Manager recommends which demands should be accepted, deferred and declined. Accepted demands are prioritized and authorized for planning and execution. Deferred demands are promising but lack resources or budget right now; revisit next quarter. Declined demands do not align with strategy or lack sufficient business value. Communicate decisions to Business Owners: accepted demands with approval to proceed, deferred demands with timeline for reconsideration, declined demands with reasoning so they understand the decision. Document all decisions in ServiceNow for transparency and compliance.

Portfolio Balancing and Trade-Offs

The portfolio often receives more demand than resources can handle. Portfolio Manager must make trade-offs: which demands deliver the most value? Which are most urgent? When one demand is accepted, what is deferred or declined? Communicate these trade-offs clearly to stakeholders so they understand the constraints and decisions.

Document decisions in the portfolio system so there is a clear audit trail showing what was prioritized and why.

When demand exceeds capacity, have a clear decision: reduce scope, extend timeline or secure additional resources. One of these three must happen; ignoring the constraint leads to overcommitment.

Where role design goes wrong before anyone logs in

A RACI chart for demand management looks settled once it is drawn. Every activity has one accountable name and the boxes are filled in. The trouble starts when the same chart is used to assign people in the tool. A planner who is also the approver of their own recommendations, a sponsor who can change the scope of a demand after the forum has ranked it, or a demand manager who is the only person able to run the monthly close all represent gaps that the chart did not show. The RACI is a statement of intent. The role model in the system is where that intent either holds or breaks.

The reader here is the ServiceNow administrator and the demand governance lead who must turn a responsibility chart into roles and assignments that will hold up under audit and during holidays. It assumes the decisions have already been named and concentrates on the places where the roles collide.

Conflicts to check before assigning people

The table lists the pairings of responsibility that most often collide in a demand process. For each one, the mitigation is a structural choice, not a reminder to behave well.

The deputy is often the most neglected role. A process that depends on one named person to run a decision cycle can stall the first time that person is away, and a hurried deputy appointed in the moment is often given more access than the role needs. Name the deputy at design time, give them the same permissions as the primary holder for the specific tasks they cover, and test that the handover works before the first real absence.

Checking the chart against the tool

Use this sequence to confirm that the RACI can be run as assigned. It takes less time than a review after go-live, and it catches the gaps that matter most.

1. Take each activity in the RACI and write the record, state change or screen where it happens in the tool. An activity that has no home in the tool needs one or it will be done outside the system.
2. Check that exactly one person or group holds the accountable letter for each activity, and that the same person does not also hold the approval for work they are accountable for.
3. Confirm that every activity with an accountable owner has a named deputy who can perform it.
4. Walk through one real demand from submission to closure, with each role played by its named holder, and note every point where the person has to ask someone else for access.
5. Resolve the access requests from that walk-through by changing the role design, not by granting extra roles to individuals.
6. Record the final assignment in a single list that the governance owner signs, and keep the signed version next to the RACI.

Onboarding and changing roles without losing the design

Many role problems appear after go-live, when people move. A new planner is given the access of the person they replaced, including permissions they were never meant to hold, because copying an existing user is faster than reading the role design. Prevent this by making the role, not the person, the unit of assignment, and by requiring the governance owner to approve any change that adds an approval right. When a role changes its responsibilities, update the RACI first and then the tool, so the document never describes a process the system does not support.

Questions about roles and accountability

Can one person hold two roles in the same demand?

Sometimes, for small teams, but only where the conflict is named and a compensating check exists. For example, a planner who sponsors a request can be allowed to hold both roles if the forum reviews every request that person sponsors. Record the exception, and review it when the team grows.

Should the RACI cover the exceptions process?

Yes. Exceptions are where the RACI is tested hardest, because they bypass the normal path. Add a row for each exception type, name the executive who may approve it, and state the expiry of the approval. An exception without an owner can be approved by whoever is available.

How many people should be accountable for one decision?

One. Several people can be responsible for doing the work, and several can be consulted, but accountability that is shared tends to mean nobody is answerable when the decision is challenged.

What is the minimum evidence that a RACI is working?

A set of recent decisions in which each one can be traced to the accountable person, and in which no decision was made by someone outside the chart without a recorded exception. Check it quarterly, and treat any untraceable decision as a design fault rather than a personal failing.

Have the role design reviewed with the team

The page on security and access design covers how the roles are protected once they are assigned, and the governance model sets out the decision rights that the RACI must reflect.