ServiceNow Strategic Portfolio Management Governance Model

Establishing Portfolio Governance Forums

Portfolio governance requires multiple forums at different levels: a Portfolio Review Board meets quarterly to assess portfolio alignment and investment decisions, a Project Intake Committee meets monthly to screen and approve project requests, a Demand Management Team meets weekly to prioritise and allocate resources, and a Portfolio Steering Committee meets annually to set portfolio strategy and policy.

Define membership for each forum: Intake includes business unit leads, finance, IT leadership; Demand includes project office, resource managers, IT; Steering includes CFO, COO, CIO, and business heads. These forums create checks and balances: no single person controls portfolio decisions.

Portfolio Standards and Criteria

Define project selection criteria: strategic alignment (does this project advance our strategy?), business value (what is the expected benefit?), resource feasibility (do we have capacity?), risk (what are the known risks?), and interdependencies (does this project depend on other projects?).

Document decision rules: projects aligned with strategic goals are prioritised higher than opportunistic projects; projects with proven business cases are prioritised over projects with estimated benefits; projects that enable other high-value projects are considered as prerequisites.

Review and update standards annually. As the business strategy changes, your portfolio criteria should change too. If emerging risks (regulatory, competitive, technical) become important, add them to your selection criteria.

Project Request Intake and Screening

Establish an intake process: project sponsors submit requests with a standard form (project description, expected benefit, resource requirements, timeline, risks). The Project Intake Committee reviews requests against selection criteria and makes a go/no-go decision within an agreed time of submission.

Build a project backlog: intake decisions create a prioritised queue of approved projects. Projects move from the backlog to active work as resources become available. This prevents portfolio overload and ensures that only vetted, prioritised projects start.

Change Control for Portfolio Changes

The portfolio changes as new information emerges: a project completes early or late, new urgent requests arrive, resource constraints change, or strategic priorities shift. Define change control: when can a project be added, stopped, or changed without full review? When does it require Steering Committee approval?

Example: a project can change timeline by up to 2 weeks without approval; changes over 2 weeks require Project Intake Committee approval. A project can change scope within the original budget; changes over budget require Intake Committee approval. Projects affecting other projects require Steering Committee approval.

Portfolio Balancing and Demand Management

Portfolio balancing is the process of selecting which projects to fund given limited resources and budget. The Demand Management Team analyzes: which projects have highest business value per resource dollar, which projects are prerequisites for other projects, which projects have long lead times and should start early, and which projects are high-risk and need contingency.

Create a visual portfolio map: plot projects by strategic value and resource cost. This shows gaps (are you over-investing in IT and under-investing in customer experience?) and imbalances (are too many projects competing for the same skills?).

Resource Allocation and Capacity Planning

Resource management is intertwined with portfolio management. Define capacity: how many person-months of engineering, business analysis, project management are available this year? Allocate capacity to approved projects based on their priority and dependencies.

Build a resource forecast: for each key skill (database architect, security engineer, business analyst), track available capacity and allocated capacity by project. If allocated capacity exceeds available capacity, you are over-committed, and the Demand Management Team must resolve it by descoping projects, hiring, or deferring lower-priority work.

Portfolio Performance Metrics and Reporting

Track: portfolio value delivery (are projects delivering expected benefits?), schedule performance (are projects on time?), resource utilisation (are we running lean or with excess capacity?), risk trends (are known risks increasing or decreasing?), and portfolio alignment (what fraction of active work is aligned with strategy?).

Report quarterly to Steering Committee: summary of active projects, progress against milestones, top risks and issues, resource capacity status, and forecast of benefits realisation. Use these reports to make quarterly adjustments to the portfolio.

Benefits Realisation and Project Closure

Capture expected benefits during intake: what is the business case for this project? After project completion, measure actual benefits: did we achieve the expected value? Create a benefits tracking process: for each project, assign a benefits owner who monitors and reports on realisation.

Use benefits data to improve portfolio selection over time. If certain types of projects consistently over-deliver on benefits, prioritise similar projects. If others under-deliver, investigate why and adjust your selection criteria or project management approach.

Portfolio Review and Rebalancing

Conduct quarterly portfolio reviews: for each active project, assess progress, risks, and realisation likelihood. For projects in the backlog, assess if priorities have changed and if rebalancing is needed. Use this forum to stop projects that are no longer valuable, accelerate high-value projects, or adjust resource allocation.

Maintain discipline: if a project is deprioritised in the backlog, do not let it restart without re-entering the intake process. If a project is stopped, conduct a project shutdown review to capture lessons learned.

Decision rights a forum can actually hold

The strength of a governance model is the list of decisions it names and the person who holds each one. Many portfolio charters describe a committee and a cadence but never say who may approve a change to a baseline, or who may stop a funded item when the sponsor is unavailable. The table below sets out the decision rights most forums need to write down before the first meeting, with the record where each decision should appear.

What the forum should refuse to decide

A forum that tries to decide everything decides nothing well. Three kinds of decision belong outside it. The first is delivery detail, such as sprint content or the order of tasks inside a project, which the delivery lead owns. The second is a change that sits inside an approved baseline and does not alter the funded amount or the benefit promise. The third is anything the sponsor can decide alone under the charter’s own limits. Writing these exclusions into the charter protects the forum’s time for the decisions that really need a group.

Escalation that does not bypass the forum

Escalations are where governance quietly breaks. A sponsor who cannot get a decision at the next meeting goes to an executive in the corridor, and the decision is made without the record. A workable rule is that any escalation is logged as a request to the forum, with the executive named as the person asking. The forum can then decide in an out-of-cycle session, or confirm the executive’s decision and record it. Either way, the record exists.

Records that prove a decision was made

An audit or a dispute later tends to ask about the decision itself, the person who took it, and the evidence behind it. Each decision should therefore produce a record with the decision, the decider, the date and a short statement of the evidence used. Minutes alone rarely meet this standard, because they are written after the meeting and often omit the trade-off. Structured fields on the decision record answer the three questions directly.

Reviewing the governance model itself

1. Collect every decision recorded in the last planning cycle and note which ones were made by the right person under the charter.
2. List every decision that was taken outside the forum and ask whether the charter should have covered it.
3. Check that the forum’s membership still matches the people who fund and deliver the portfolio, since reorganizations often move ownership without updating the charter.
4. Revise the charter with a version note and a change summary, and circulate it to every member before the next meeting.

The platform governance charter approach is a useful reference for how that revision should be written and approved, even though the subject here is portfolio rather than platform decisions.

Intake and prioritization sit upstream of the forum

A forum that sees every request in raw form will spend its time sorting them. Intake should filter requests against the stated strategy and send only the scored ones forward. The demand intake and prioritization post covers the filter in more depth, and the demand management governance model is the intake-side counterpart.

How many members does a forum need?

Enough to hold the decision rights in the table and no more. The usual core is the sponsor for each major funding line, a finance partner and a delivery representative. Additional members are useful as advisers, but a forum that votes with twenty people rarely reaches a decision a sponsor is willing to own.

Can the forum delegate approvals to a smaller group?

It can, if the delegation is written into the charter with a limit that the group can check against the record. Delegation without a limit is a common route by which a forum loses control of funding, because each small approval looks reasonable on its own.

What happens when a sponsor leaves?

The charter should name who inherits the sponsor’s decisions, and the handover should be recorded against each open item. An item without a sponsor should not advance to its next stage until one is appointed, because the decisions that item needs will otherwise be made by default.

Does the governance model need a tool to work?

No. A model can run on a shared register for a while. The tool adds value when the number of decisions is large enough that the register cannot be kept current, or when the audit questions become frequent enough that answering them by hand costs more than the configuration.