Common ServiceNow Project Portfolio Management Mistakes and How to Avoid Them

This page names the portfolio management mistakes that most often make a ServiceNow project portfolio unreliable, describes the symptoms and root cause of each, and sets out the fix and the prevention step that stop it recurring.

Mistake 1: Overpromising Capacity

The most common mistake: the portfolio shows 200 projects committed for the next year, but the organization has capacity for 80. This happens because no one consolidates all project requests; each department submits a list without visibility into competing priorities. When reality hits (resources are allocated, timelines slip, quality suffers), blame falls on the execution team rather than the flawed plan.

Symptom: Repeated project delays, teams working weekends to meet commitments, quality issues because work is rushed, high staff turnover from burnout.

Root cause: Portfolio is accepted at face value without capacity-load analysis. No one asks, “Do we have enough engineers, product managers, and testers to deliver all this simultaneously?”

Fix: In portfolio planning, explicitly calculate capacity. For each resource type (engineers, testers, designers), estimate available hours per quarter. For each proposed project, estimate the demand. If demand exceeds supply, force a prioritization conversation: which projects are truly business-critical, which can be deferred, which should be abandoned.

Prevention: Make capacity visible. Create a heat map showing demand versus available capacity by quarter and resource type. Escalate to the portfolio governance board if demand exceeds capacity. Make explicit trade-off decisions: “We can do A and B, but not C” rather than committing to all three and missing all three.

Mistake 2: Orphaned Projects

Projects get into the portfolio with good intent but no sponsor, no business case that was actually validated, and no one willing to make hard trade-off decisions about them. They languish: not completed because they are not a priority, but not killed because the sponsoring department hasn’t formally withdrawn them. Meanwhile, resources are nominally allocated to them, reducing the available pool for active work.

Symptom: Projects in “waiting” or “on hold” status for months with no visible progress or sponsor activity; resources on these projects are pulled away to handle urgent work; the portfolio backlog is thick with zombie projects.

Root cause: Portfolio has no clear owner responsible for pruning. Projects are added but rarely removed, and there is no regular governance review forcing decisions about stalled work.

Fix: Implement a quarterly portfolio review where the governance board explicitly assesses each project: is it still business-critical, is a sponsor actively managing it, and is it on track. If not, kill it. Killing a project is a legitimate outcome and clears capacity for active work.

Prevention: Require a business case for every project added to the portfolio. At quarterly reviews, re-validate the business case: has the market changed, has the business need changed, would we add this project today if it wasn’t already in the portfolio? If the honest answer is no, retire it.

Mistake 3: Poor Prioritization Logic

The portfolio is “prioritized” but everyone who looks at it wonders how. Project A is ranked higher than Project B even though B is worth more money, B is lower risk, and B is needed by more customers. Priorities look arbitrary because they are: different stakeholders had different reasons for their preferences and no one reconciled them.

Symptom: Projects in the portfolio don’t progress in priority order (lower-ranked projects start before higher-ranked ones), stakeholders keep arguing about priority, and the team never feels confident they are working on the most important things.

Root cause: No explicit prioritization criteria. Priorities were decided through informal discussions and politics, not a consistent framework.

Fix: Establish prioritization criteria and apply them consistently to all projects. Common criteria: strategic importance (does this project advance a stated business strategy), financial return (revenue or cost savings), risk (executing this project reduces a critical risk), and customer impact (how many customers are affected, how much does this matter to them).

Score each project against each criterion (e.g., strategic importance on a scale of 1 to 5) and weight the criteria by business priority (a strategic project can be weighted above a purely financial one). The resulting score is the priority ranking. This doesn’t eliminate trade-offs, but it makes them explicit and defensible.

Prevention: Review and reset prioritization criteria annually. As the business strategy evolves, the relative importance of criteria changes. A startup focused on survival might weight financial return heavily; a mature company might weight customer satisfaction or employee retention more heavily. Align prioritization criteria to the current strategy.

Mistake 4: No Resource Leveling

The portfolio is theoretically balanced, but resource allocation is lumpy. Some quarters have plenty of capacity and projects stall; other quarters are overloaded and projects slip. Resources are assigned to projects inefficiently—a senior architect is assigned to work that a junior engineer could do, creating bottlenecks elsewhere.

Symptom: Some quarters are overloaded, others have idle capacity; the team complains of thrashing (constantly re-prioritizing work); projects are in “waiting for architect” status for weeks.

Root cause: No active resource management. Projects are scoped based on scope, not resource availability. No one is managing the resource supply side (hiring, training, cross-skilling) to match demand.

Fix: Resource level the portfolio. Spread high-demand projects across quarters to balance the load. For heavily skilled roles (architects, senior engineers), look for junior projects that junior team members can execute with mentoring, freeing the senior people for high-priority work. Consider outsourcing low-complexity projects or hiring contractors for spikes in demand.

Prevention: Measure resource utilization quarterly. Are your most skilled people overallocated, are junior people underutilized, are there bottleneck roles? Use utilization data to guide resource planning: hire in bottleneck areas, develop junior staff through mentored project work, or consider training in adjacent skills to reduce dependencies.

Mistake 5: Weak Portfolio Governance

There is a portfolio, but governance is weak. The steering committee meets quarterly, reviews status reports, and approves a few new projects, but makes no hard trade-off decisions. Requests for scope change on existing projects are routinely approved, inflating timelines without corresponding descoping or priority adjustment. New opportunities pop up mid-year and get crammed into the portfolio without displacing lower-priority work.

Symptom: Portfolio commitment is unreliable (planned work is consistently missed), scope creep is endemic, stakeholders feel unheard because lower-priority projects never start, team morale is low because priorities are unclear and constantly shifting.

Root cause: Governance lacks teeth. The steering committee has no authority to say no, or is unwilling to make enemies by killing projects.

Fix: Establish clear governance authority and decisions. The portfolio steering committee has authority to approve, defer, or kill projects; to approve scope changes; and to resolve resource conflicts. Define escalation paths: if a department head thinks a project should be higher priority, what is the process to re-prioritize? (Usually: present new data to the committee, make the case, accept the committee’s decision.)

Make governance decisions visible and documented. When a project is killed, explain why in a one-pager so the sponsoring department understands the trade-off. When priorities change, explain what triggered the change. Transparency builds credibility.

Prevention: Establish an intake process for new project requests. New requests are added to a backlog, not automatically into the portfolio. They compete for a portfolio slot at the next governance review. This forces explicit trade-off discussions: if we add this new project, which lower-priority project comes out?

Mistakes that begin in configuration, before any project is entered

Some portfolio failures are visible long before a project starts slipping. They happen when the tool is set up to match whatever the team already does, instead of forcing a few decisions into the open first. Two errors are common. The first is building a stage-gate model with more gates than the governance board will ever attend. The second is copying the old spreadsheet’s columns into the register, which preserves every inconsistency the spreadsheet had. Each of these is cheap to avoid and expensive to unwind once a year of records depends on the structure.

Where a register goes wrong without anyone noticing

The quieter failures build up over several review cycles. A sponsor changes midway through a program, and the new sponsor inherits a plan they never approved. Percent-complete figures are reported without exit criteria, so a project can read as nearly finished for months. Projects that were paused are sometimes never moved to a paused status, which keeps their allocated people counted as busy. Each of these can be caught by a short question at review: who approved this plan, what finishes it, and is the person named here still the person deciding. Schedule measures are set out in the KPIs and metrics guide, and the integration patterns guide covers how program and project data flows between systems.

Should we model every stage of our delivery method in the portfolio?

No. The portfolio needs the stages at which money or people are committed. Detailed sprint or task structure belongs to the delivery teams, and mirroring it in the register creates maintenance work without improving any decision.

Is it a mistake to let project managers update their own status?

Letting them update status is sound, provided the portfolio manager confirms changes that affect funding or dates. Unconfirmed self-reported status is how a register can end up showing green on every line.

What is the first sign that a configuration mistake has already happened?

Users start keeping their own list beside the tool. When people trust a spreadsheet more than the register, the structure of the register is usually the reason, and the fix is often to remove a field rather than add a report.

Next step

The governance model guide covers the decision structure that should sit behind the register.