Common ServiceNow Strategic Portfolio Management Mistakes and How to Avoid Them
Common mistakes in ServiceNow Strategic Portfolio Management are the recurring gaps between strategy, governance, business cases, dependencies and delivery that leave a portfolio funding the wrong work. The page sets out each mistake with the fix a portfolio owner can apply and the checks that show whether the portfolio is still going wrong.
Mistake: Portfolio Strategy Not Aligned with Business Strategy
Strategic Portfolio Management prioritises work to support business goals. Yet many organisations launch Portfolio Management without explicitly connecting portfolios to strategy. Teams end up managing projects without clear strategic direction: are these projects advancing the business? Or are they legacy work that should be stopped?
The fix: before implementing Portfolio Management, make strategy explicit. What are the top three to five business goals for the year? Which portfolios support which goals? For example, if growth is a goal, portfolio priorities should reflect customer acquisition and retention work. If risk reduction is a goal, security and compliance projects should rank high. Document this connection. In Portfolio Management, tag each portfolio with the strategy it supports. Quarterly, review: are we still prioritising the right portfolios, or has strategy shifted and priorities need to shift with it?
Mistake: Governance and Decision-Making Not Defined
Portfolio decisions matter: which projects get funded, which get stopped, which are prioritised? Yet many organisations never define who makes these decisions. Is it the CIO? A steering committee? Individual business units? Unclear decision-making leads to conflict and delays.
The fix: establish a portfolio governance committee. Define membership (CIO, CFO, business unit leaders, maybe customers). Define decision authority: when can the committee make autonomous decisions vs. when must they escalate? Define frequency of meetings and decision cycles. Document all decisions in ServiceNow. When someone asks “why did this project get cancelled?” you can point to the decision rationale.
Mistake: Incomplete or Outdated Business Cases
Business cases justify projects: they articulate the business benefit, the cost, the risk, and the timeline. Yet many organisations require business cases at project start but never update them. A project that promised 1.2 million revenue benefit might deliver only 500k, but the business case is never revised. Teams operate based on outdated assumptions.
The fix: treat business cases as living documents. Require updates at major gates: project approval, mid-project checkpoint, and project closure. If a project’s benefit or cost has changed significantly, update the business case. In Portfolio Management, track how actual outcomes compare to projected outcomes. This feedback loop improves estimation and drives accountability.
Mistake: Dependencies Between Projects Not Managed
Projects rarely work in isolation. Project A delivers data that Project B needs. Project C depends on infrastructure Project D is building. If dependencies are not managed, projects block each other, timelines slip, and teams blame each other for delays.
The fix: map dependencies explicitly. When a project is proposed, identify what other projects it depends on and what projects depend on it. In Portfolio Management, consider dependencies when sequencing projects. If Project B depends on Project A, do not start B before A is far enough along. Manage handoffs and data transfers between projects with clear agreements about what will be delivered and when.
Mistake: Execution Not Tracked Against Portfolio Priorities
A portfolio prioritises work. Yet on the ground, teams sometimes ignore priorities and execute based on what they have budget for, what is loudest, or what they prefer. Strategic prioritisation becomes theoretical rather than real.
The fix: enforce prioritisation through resource allocation. When Portfolio Management says Project A is high priority and Project B is low, allocate more staff and budget to A. Make it hard for teams to work on low-priority work by starving it of resources. Measure and report on what percentage of team capacity is spent on high-priority vs. low-priority work. This drives accountability.
Mistake: Weak Execution Visibility
Portfolio Management provides strategic oversight, but execution details belong in project management. Yet if Portfolio Management and Project Management systems are disconnected, leaders have outdated visibility: the portfolio says a project is on track, but project teams know it is behind. Misalignment creates poor decisions (continue investing in a failing project, or kill a nearly complete project).
The fix: integrate Portfolio Management with project-level tracking. Portfolio dashboards should aggregate data from projects. If ten projects are in a portfolio, the portfolio status should reflect the health of all ten, not just executive perception. Train project managers to update their projects regularly; portfolio status depends on current project data.
Mistake: Portfolio Imbalance
Portfolios should balance different types of work: run-the-business (keeping current systems running), grow-the-business (new capabilities and revenue), and transform-the-business (structural change). Many organisations focus on one and neglect the others. If they focus only on run-the-business, transformation stalls and they fall behind competitors. If they focus only on transform, current systems deteriorate and customers become unhappy.
The fix: establish portfolio mix targets. Define how capacity should be split across run-the-business, grow-the-business, and transform-the-business work. One common model allocates the majority to run, a portion to grow, and a smaller portion to transform, but adjust to your business needs. Periodically review portfolio composition and rebalance if needed. This ensures the organisation is maintaining current operations while also innovating and transforming.
Mistake: Leadership Resistance to Portfolio Discipline
Portfolio Management requires discipline: stopping low-priority work even if it is politically popular, saying no to requests that do not align with strategy, deferring work that fits but cannot be resourced. Leaders sometimes resist this discipline, pressuring to start new projects even when the portfolio is full. This undermines portfolio management.
The fix: establish clear escalation rules. If someone wants to add work to a full portfolio, something must be removed or deferred to make room. Make trade-offs visible: adding this project means delaying that project. Leaders see the trade-off and can make an informed decision. If they still insist, document their decision and the trade-off they accepted. This builds accountability.
Reading the symptoms before naming the mistake
Most portfolio problems are first noticed as a number that does not look right in a steering pack. The temptation is to treat the number as a judgment call about priorities. In practice, many of these numbers come from the records underneath, and the fix is a data fix rather than a governance argument. The table below pairs what people see with the mechanism that usually produces it, so a reviewer knows where to look first.
| What the steering pack shows | Usual underlying cause | First check |
|---|---|---|
| Project list does not add up to the funded total | A demand was converted into a project and both records stayed open | Count work items by their source record and look for pairs |
| Benefit realization is high every quarter | Benefit breakdowns were entered as targets, not as recorded outcomes | Read the breakdown type on a sample of records |
| An investment shows no spend while its project is busy | The investment was never linked to a work item | Query investments by funding reference and list the empty ones |
| Scores for an item differ from the score at approval | Criteria were edited after the decision without a note | Check the audit trail on the scoring criteria record |
Demand converted to a project, then both records kept open
A common pattern is a demand approved for delivery and converted into a project, while the original demand stays active because nobody closed it. Both records then carry budget and status, and any total that sums across work items counts the same effort twice. The mistake is procedural rather than technical: the conversion step has no rule for what happens to the source record. The fix is to make the conversion close or freeze the demand, and to write one line in the decision record saying which work item now owns the budget.
Cost plans read as actual spend
Cost plans are where planning happens, so they look like accounting records. A finance partner who sees a total on a cost plan will often read it as money spent. The distinction matters because actual expense is recorded against tasks, and a cost plan on a demand does not create expense lines. Reports that mix the two are wrong in a way that is hard to spot, because the totals look plausible. The corrective step is a labeled report with two columns: planned from cost plans, and actual from task expense lines, with no combined figure offered unless the person reading it asks for one.
Benefits entered once and never restated
An approval records a benefit estimate. Some organizations then track benefit breakdowns against that estimate, while others overwrite the estimate with later figures, so the original promise disappears from the record. Neither approach is wrong on its own, but mixing them is. The working practice is to snapshot the approval-stage baseline when the investment is approved, to record every later restatement as a dated change with a reason, and to report variance against the baseline rather than against whichever figure was entered last.
An audit sequence for a portfolio already in use
When an existing portfolio is showing these symptoms, a structured audit is more reliable than a clean-up driven by whoever complained loudest.
- Export the list of funded investments and the list of work items, then match them on the funding reference and mark every orphan on either side.
- Find every pair of records that refer to the same original request and decide which one owns the budget going forward.
- For each investment, compare the planned totals per fiscal period with the approved amount, and mark any investment where they differ.
- Sample benefit breakdowns and confirm each is recorded as an outcome with a date, not as a target.
- Write a short note for each correction, naming the person who approved it. The demand management mistakes guide covers common intake problems, and the project portfolio mistakes guide covers common delivery problems.
When a mistake is not a mistake
Not every irregular record is an error. A cost plan may be built on a demand before any work starts, because the budget conversation happens earlier than the approval. Two work items may legitimately share an investment when one funds discovery and the other delivery. Correcting these too quickly removes information the finance team needs. Before changing a record, check whether the irregularity follows a rule someone agreed, and only correct the ones that break it.
Where the reporting layer hides these mistakes
Dashboards tend to smooth over exactly the problems described above, because they aggregate. A chart of total investment by quarter will look stable even when half the investments are unlinked. The defense is a small set of exception views that list orphans, duplicates and unreconciled periods explicitly. Those views are cheap to build and should be reviewed before the headline dashboard is trusted.
Are these mistakes only found in the first year?
They appear first during rollout, but they reappear each time intake or ownership changes, for example through a new form or a reorganization, a reorganization that moves ownership, or a switch to a new budget cycle. A check that runs at the start of each planning cycle can catch many of them before they reach a steering pack.
Should we correct historical records or only current ones?
Correct current records and leave historical records alone unless they feed a live decision. Rewriting history makes past reports impossible to reconcile. Add a dated note to historical records where a known error affects a decision that has already been made.
Who should be allowed to merge duplicate records?
The person who owns the budget for the surviving record, with the portfolio analyst checking the link. A merge done by an administrator without budget ownership removes evidence that someone will later need when a decision is questioned.
What if the audit finds more problems than the team can fix?
Rank them by their effect on a decision that is due, not by how untidy they look. Fix the orphans and duplicates that affect the next funding decision, record the rest as known issues with owners, and schedule them into the next review rather than trying to clear the backlog in one pass.
Findings from an audit like this are easiest to act on once they are sorted against the decision calendar.
Frequently asked questions
How often should portfolio priorities be reviewed?
Typically quarterly, aligned with business reviews and budget cycles. Some organisations review more frequently if the business environment is volatile. Do not review so frequently that projects are constantly reprioritised; that creates instability. Quarterly gives enough time for projects to make progress while allowing adjustment if strategy or circumstances change.
What should happen to a project if its business case is no longer valid?
Stop or significantly redesign the project. A project without a business case is work without purpose. If the original benefit is no longer expected and no new benefit case can be made, kill the project and redeploy resources to higher-priority work. This is a strategic decision that belongs in portfolio governance.
Should portfolio committees make funding decisions, or should business units?
A hybrid approach often works: portfolio committee establishes priorities and overall funding levels, then business units decide how to execute within those constraints. This balances strategic oversight (committee) with operational autonomy (business units). Clear boundaries prevent conflict.
Related guides
Related Oblytech services
Where this topic turns into delivery work, these are the Oblytech services that cover it.
Planning, running or fixing a ServiceNow programme? Tell us where you are and we will suggest a sensible next step.
Contact us