ServiceNow Project Portfolio Management Requirements Workshop Questions

This page helps a project portfolio team decide which questions to put to the business before Project Portfolio Management is configured, grouped by governance, budget, capacity, benefits, strategy and tooling, and what each answer changes in the build.

Portfolio Governance and Decision-Making

How do investment decisions get made today? Who decides whether a proposed project gets funded? Is there a formal governance process or do decisions happen informally? Understanding current decision-making informs portfolio governance design.

Answer impact: Portfolio Management requires clear governance. If decisions are informal, Project Portfolio Management (PPM) will expose inconsistency. You will need to design a formal process: who submits project requests, what evaluation criteria apply, who votes on approval, how are conflicts resolved. Without clear governance, PPM becomes a tool that highlights broken processes.

What criteria do you use to evaluate projects? Return on investment, strategic alignment, compliance urgency, customer demand? Different criteria drive different prioritization. If you use ROI, you need financial data for every project. If you use strategic alignment, you need a clear strategy and a way to rate projects against it.

Warning sign: if leadership cannot articulate clear investment criteria, portfolio management will struggle. Clarify decision criteria before implementing PPM.

Planning Cycle and Budget Constraints

How often does budget planning happen (annual, quarterly)? How is budget allocated across portfolio (equal per department, percentage of revenue, strategic priorities)? Do you have enough budget to fund all high-priority projects, or do you regularly have to choose between projects?

Answer impact: Portfolio management requires a planning cadence. An annual planning cycle limits responsiveness to urgent requests. Quarterly planning allows adjustments but requires more governance overhead. The budget model (how much each department or business unit gets) directly impacts portfolio configuration.

Do you track multi-year project budgets or commit annual budgets only? Multi-year visibility helps with large strategic projects; annual budgeting is simpler but may force cancellation of multi-year work if priorities shift.

Resource Capacity and Constraints

How many project managers, developers, or specialized resources (data scientists, architects) do you have? Which resources are scarce and constrain project delivery? Resource capacity is often the real constraint, not money.

Answer impact: If you are resource-constrained (say, only five architects for 20 projects), Portfolio Management must schedule projects to avoid resource conflicts. If you are budget-constrained, PPM prioritizes based on budget. Different constraints require different portfolio strategies.

Can resources move between projects, or are they dedicated? Dedicated resources are simpler to schedule but less flexible. Shared resources allow higher utilization but require detailed scheduling.

Benefits Tracking and Business Case

Do projects have documented business cases that quantify expected benefits? Do you track whether projects delivered those benefits after completion? Or are projects launched based on rough estimates that are never validated?

Answer impact: Portfolio Management can track benefits, but only if projects define them upfront. If business cases are vague or missing, portfolio metrics will be weak. Implement disciplined business case development: every project must document what benefits it will deliver, how they are measured, and when they will be realized.

Warning sign: if most completed projects have no documented benefits and nobody knows if they delivered value, portfolio management will struggle. Build a benefits realization practice alongside PPM.

Strategic Alignment and Portfolio Balance

Does your organization have a clear strategy? If yes, are projects evaluated against it? Your portfolio should balance run-the-business projects (maintaining existing systems), strategic initiatives (supporting long-term goals), and experimental work (innovation and exploration).

Answer impact: Portfolio Management can align projects to strategy, but strategy must be clear and stable. If strategy changes every quarter, portfolio alignment becomes difficult. A common approach dedicates most capacity to keeping systems running, a significant portion to strategic initiatives, and a smaller portion to experimentation. Your balance should reflect your organizational priorities and risk tolerance.

How do you prevent the portfolio from becoming entirely focused on support work? This is a common problem; maintenance work expands to fill available resources. Portfolio management helps, but you need clear prioritization rules and someone enforcing them. Without discipline, innovation and strategic work get crowded out.

Portfolio Tool and Process Maturity

Are projects tracked today in a central system or scattered across spreadsheets and email? Do you have project portfolio data you can analyze, or is portfolio information distributed and hard to aggregate?

Answer impact: If data is scattered, implementing Portfolio Management requires data consolidation and migration. This is often more work than the PPM configuration itself.

Running the Workshop Series in a Useful Order

Discovery sessions for portfolio tooling often drift. They either turn into a long list of wishes that nobody can rank, or they stay so abstract that the configuration team has to guess what the answers mean. The fix is sequencing. Run the sessions so that each one produces a decision the next session depends on, and record every answer in a decision log rather than a meeting note. A workable series usually covers decision rights first, then money, then people, then the data that will feed the tool.

Keep each session to the people who can actually settle the topic in the room. A workshop on funding rules with no finance approver present will produce a draft that finance later rejects, and the rework lands on the configuration team.

Session Sequence and the Output Each Should Produce

For the background on how these areas fit together in the platform, the plain-language overview of portfolio management is a useful reference to share with attendees before the first session.

A Procedure for Each Session

1. Send the question list at least a week ahead, marking the three questions that carry the most weight so participants can prepare.
2. Open by restating the decision the session must reach. Do not start with open discussion.
3. Ask each question in turn, and when an answer is a preference, ask what evidence would change it.
4. Read the draft decision back before the room empties. A decision that nobody can repeat is not yet a decision.
5. Log each decision with its owner, date and the open items it created, then send the log within the same working day.
6. Hold the next session only after the previous log has been confirmed by the approver named in it.

Failure Modes Worth Designing Around

The first failure is answers recorded as opinions. “We should prioritize strategic work” is a sentiment. The workshop needs the rule that turns it into a ranking, such as which strategic themes outrank operational requests when both are waiting for the same engineer. Without that rule, the configuration will reflect whichever participant spoke last.

The second failure is an unowned data field. A workshop may agree that every project needs a business owner, then discover that three systems hold owner records and none is designated as authoritative. Add a column to the decision log for the system of record, and do not close the item until one system is named.

The third failure is scope creep disguised as completeness. Attendees add reporting requests, approval steps and integration wishes faster than the team can assess them. Park anything outside the first release in a separate backlog, marked with the decision it depends on, so it can be revisited without reopening settled questions.

Signs the Workshops Are Producing Usable Input

• Every decision in the log has a named owner and a date.
• Configuration questions raised during build can be answered from the log without a new meeting.
• The same disagreement does not reappear in a later session under different wording.
• Approvers recognize their own decision when they see the draft configuration.

When a Workshop Series Is the Wrong Tool

If the organization has not agreed on what a project is, or if two business units run portfolios that will never share funding, a workshop series will only expose that disagreement. In those cases the first output should be a short charter that settles the definitions and the boundaries, and the requirements work should wait. Running workshops to force agreement on a question that leadership has not yet decided tends to produce a configuration that is quickly rebuilt.

Frequently Asked About the Workshops

How many sessions do we actually need?

The count depends on how many decisions are still open when you start, not on the size of the program. Track open decisions after each session. When the list stops shrinking, the series has reached diminishing returns and the remaining questions belong to the build phase or to a governance review.

Should the vendor or implementation partner run the workshops?

A partner can facilitate and draft the decision log, but the approver must make the calls. Partners who make funding or prioritization decisions on behalf of the client create a configuration that nobody inside the organization owns. Agree on who holds each decision before the first session.

What if two stakeholders give opposite answers?

Record both positions, name the approver who can settle the disagreement, and fix a date for the ruling. Do not let the configuration team pick one silently. A recorded conflict is much cheaper to resolve than a configuration that quietly favors one view.

How do we handle questions that depend on decisions made later?

Mark them as dependent in the log and link them to the decision they wait on. This keeps the series moving without pretending the open item is settled. When the dependency is resolved, the linked items become the agenda for a short follow-up.

Can the workshop answers be reused for demand intake?

Many intake answers carry over, especially the fields a request must include and the owners who review it. The demand management workshop questions cover the intake side in more depth, so the two lists should be reconciled rather than written separately.

Next Step

The most useful outcome of any such conversation is a decision log and a named owner for each open item.