ServiceNow Strategic Portfolio Management Requirements Workshop Questions

This page helps a portfolio lead decide what a requirements workshop for strategic portfolio management must settle before any configuration starts. It sets out the questions to ask in each area of portfolio governance, and the decisions each session has to produce.

Portfolio Strategy and Strategic Alignment

Start with portfolio strategy. What’s your organization’s strategic vision for IT or technology? How does portfolio management support that vision? Are you trying to modernize applications, migrate to cloud, improve agility, or reduce cost? Portfolio strategy should connect project portfolio to enterprise strategy.

Questions to ask: What’s your organization’s strategic vision over your planning horizon? How does IT strategy support that vision? What types of projects support strategy (modernization, cloud migration, process improvement, innovation)? What projects don’t—are there projects that should be deprioritized or stopped? How do you ensure portfolio is aligned with strategy? Answers shape portfolio governance and selection criteria in ServiceNow.

Portfolio Categorization and Project Types

Organizations often have different types of projects—strategic investments (align with strategic vision), operational improvements (improve efficiency), and business-as-usual maintenance. Different project types may have different approval processes, budgets, and timelines.

Questions to ask: How do you categorize projects in your organization? Are there formal categories (strategic, tactical, operational) or informal? Which project types need executive approval? Which can be approved by department heads? How much of your budget goes to each category? Is the balance right (are you doing enough strategic work, or just firefighting operational issues)? Answers shape portfolio structure and decision-making workflows.

Portfolio Governance and Decision-Making

Who makes portfolio decisions? Do you have a portfolio management office (PMO) or steering committee that reviews projects and makes go/no-go decisions? How often does the committee meet? What criteria do they use to make decisions (strategic alignment, cost-benefit, risk, resource availability)? How are decisions communicated to project teams?

Questions to ask: Who are the key decision-makers—CIO, CFO, business unit leaders, board? How often does the governance forum meet (monthly, quarterly)? What decision criteria are used (strategic alignment score, ROI, risk level)? How are competing projects prioritized? What authority does the PMO have (can they kill projects, or just recommend)? Answers shape governance structure and workflow in ServiceNow.

Demand and Pipeline Planning

How far in advance do you plan the portfolio—one year, three years, five years? Is there a formal demand intake process where business units request new projects? How many project requests do you typically receive versus how many you can approve and fund? How do you handle demand exceeding supply?

Questions to ask: How stable is your project pipeline (do plans change frequently or stay stable)? Do you forecast demand 12+ months ahead or plan shorter term? How much demand exceeds your execution capacity? What happens to projects that don’t get approved this year—are they carried to next year or forgotten? Answers help size portfolio management and demand management processes.

Resource Planning and Allocation

Portfolio management depends on resource planning. What resources does your organization have to execute projects—people, budget, vendors, infrastructure? How are resources allocated across competing projects? If resources are limited, who decides which projects get people and which wait?

Questions to ask: How many technical staff do you have available for project work versus operational support? Do you have resource bottlenecks (certain skills are scarce)? How do you balance planned project work against unplanned urgent work? Is resource allocation driven by project priority or department politics? Answers inform portfolio execution capability and resource management design.

Benefits Realization and Value Tracking

Why do projects matter? Most projects promise benefits (cost savings, revenue increase, risk reduction, capability improvement). Do you formally track whether projects delivered on promised benefits? Do you compare planned benefits (estimated before project starts) to actual benefits (measured after project completes)?

Questions to ask: What benefits do projects typically promise (cost savings, efficiency improvement, revenue growth, risk reduction)? Do you track actual benefits realization? How often do projects deliver less value than promised? When projects don’t deliver value, what happens (lessons learned, process improvement)? Is there accountability for benefit realization? Answers shape value tracking and post-project review processes.

Risk and Dependency Management

Large portfolios have complex dependencies—project A’s completion enables project B; resource constraints create conflicts; technology dependencies tie projects together. Portfolio management needs visibility into these dependencies and risks.

Questions to ask: What risks and dependencies exist across your portfolio (technology, resource, business, regulatory)? How do you currently track them (spreadsheets, informal awareness)? When dependencies or risks occur, how are they managed? Do you have a formal process for risk escalation? Answers shape portfolio risk management and dependency visualization requirements.

Designing the workshop around decisions, not requirements lists

Requirements workshops produce long lists that the project team then has to interpret, and the lists often do not say which requirement has an owner who will sign it off. A better workshop is organized around the decisions the portfolio must support, because each decision names a person and a record. Questions framed as decisions also reveal the requirements that are really policy questions, which the workshop cannot answer and should not try to.

Who to invite and who to leave out

A workshop with too many people can produce agreement on the easy items and avoid the hard ones. Invite the people who make the decisions in the session’s area, the person who maintains the records, and one person who will test the answers in the first cycle. Leave observers out of the decision sessions and give them the outputs afterwards. Finance should attend the funding session in person, since a baseline agreed without finance is a baseline that finance will later reject.

Pre-reading that makes the session shorter

• A one-page description of the current process as it actually runs, not as the process document says it runs.
• A sample of three or four recent funding or staffing decisions, with the records that were used to make them.
• The list of open questions from the previous session, with an owner against each one.
• A draft of the decision rights table, marked with the parts the group must confirm.

Questions that reveal a policy question in disguise

Some questions sound like requirements but cannot be answered in a workshop. “Can the system stop a project automatically when it is over budget?” is one. The answer depends on who is allowed to stop projects and under what authority, which is a governance decision. When a question of this kind comes up, record it as a policy question with an owner and a date for the decision, and move on. The workshop should not invent a rule to fill the gap.

An order for running the sessions

1. Start with strategy and goals, because every later answer refers to them.
2. Run intake and scoring next, so that the fields used for decisions are settled before funding is discussed.
3. Hold the funding and baseline session with finance present, and close it with the baseline rule written down.
4. Run the capacity session once the decision rights are known, since reallocation rights depend on them.
5. Finish with reporting, so the packs are designed from the decisions rather than from the data that happens to be available.
6. Read back each decision in the room and ask the owner to confirm it before the session closes.

Turning the outputs into a usable specification

A workshop output is only useful once it is converted into a specification that a builder can test. Each decision should map to one configuration item or one report, with its owner named. Decisions that map to nothing are often the ones nobody will follow, so review them before the specification is signed. Keep the workshop notes in the same place as the decision rights, so that a future change can be traced back to the decision it modifies.

The question sets for the sibling areas are in the demand management workshop questions, the resource management workshop questions and the project portfolio management workshop questions. The demand intake and prioritization post goes deeper on the intake side.

How long should a session run?

Long enough to reach a recorded decision on every question in the session plan, and no longer. A session that runs out of energy before its last item should be split, not extended, because the late decisions are the ones that get revisited.

What if two sponsors disagree on the baseline rule?

Record both positions, name the person who will decide between them, and set a date. Do not let the workshop choose by vote, since the person who loses the vote will then be the one who challenges the first steering pack.

Should the workshop cover reporting before the records exist?

Only at the level of the decisions the reports must support. Detailed report design before the records are stable produces mock-ups that change with every data question, and the sponsors lose confidence in the process.

Who writes the final specification?

The portfolio lead writes it, from the workshop artifacts, and the decision owners sign it. A specification written by the technical team alone will describe what can be built rather than what the portfolio has decided.

Invitations are easier to send once the session plan is settled. The ServiceNow consulting page describes the consulting services available.