OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow service portfolio practice

ServiceNow service portfolio rationalisation with a clear decision record

ServiceNow service portfolios help leaders decide what services the organisation operates, for whom, under which ownership and with what future direction. OBLYTECH helps organisations make rationalisation decisions traceable.

Discuss ServiceNow service-portfolio rationalisation

Define the service and decision being made

Describe the service outcome, users, owner, supporting capabilities, lifecycle state and decision required. Distinguish a service from an internal component or a request option. The portfolio view should make the choice visible before detailed catalogue items are reviewed.

Compare demand, value, risk and ownership

Review who uses the service, what demand it receives, which obligations or dependencies exist, where risk sits and whether an accountable owner can make decisions. Avoid relying on a single measure: a low-demand service may still be necessary, while a popular service may need redesign.

Separate portfolio from catalogue detail

The portfolio describes services and lifecycle decisions; the catalogue describes requestable options and fulfilment paths. A catalogue item may change without changing the service, and a service decision may require several catalogue changes. Keep the two views connected without treating them as the same record.

Decide whether to retain, change, combine or retire

Record the decision, evidence, owner, effective condition, user communication, dependencies and exception. If services are combined, state the new boundary and transition work. If a service is retired, state how existing users, records and support paths will be handled.

Record dependencies and transition work

Link the portfolio decision to changes, data updates, catalogue changes, knowledge updates, contracts and support preparation. Keep unresolved dependencies visible until an owner confirms the transition result. The decision is incomplete when the route to the new state is not owned.

For roadmap context, see ServiceNow strategic roadmap prioritisation. For demand decisions, review ServiceNow strategic portfolio and demand intake. For platform governance, see ServiceNow security, risk and governance.

Discuss ServiceNow service-portfolio rationalisation

Bring one service that has unclear ownership, overlapping request paths, changing demand or an uncertain lifecycle. OBLYTECH can help review the service boundary, evidence, decision and transition work.

Start the conversation

When a rationalization review is worth starting

Service portfolios grow by accretion. A team builds a request form for a single purpose, a regional office adds its own variant, an acquisition brings in a second service that does the same job, and after several years the catalog offers four routes to one outcome. Nobody decided that this should happen. A rationalization review is worth starting when the cost of that drift is visible: users cannot tell which route to take, support staff answer the same question differently by team, or a service still in the list has no owner who can say what it is for.

The review is not a cost-cutting exercise by default. It is a structured decision about which services should continue, which should be combined and which should end, and it can just as easily conclude that a neglected service needs investment. Framing the review that way at the start prevents it from being read as a hunt for savings, which tends to make service owners defensive and the evidence unreliable.

Reading usage data without drawing the wrong conclusion

Usage is the measure most often reached for and the one most likely to mislead. A service used rarely may be critical to an annual regulatory return, a service used heavily may be generating avoidable work for a single team, and a service used by no one may have been replaced by a route that users found on their own. A reviewer needs to ask what the usage means before deciding what it implies.

Signal in the dataPossible meaningQuestion to put to the service owner
Low volume, high impact when usedPeriodic or emergency service with a specific obligationWhat happens if this is unavailable in its peak period?
High volume, repeated clarifying contactDesign or wording problem, not a need for the service itselfWhich step generates the questions, and who owns that step?
Steady volume through an unofficial routeA workaround has replaced the catalog entryWhere do users actually go, and why?
Falling volume after a related changeDemand has moved to another serviceHas the receiving service been sized and owned for that demand?

Usage data should inform the question, not answer it. A decision that rests on volume alone will often reverse itself once the first user with an unmet need files a complaint.

Choosing between retain, change, combine and retire

Each outcome carries a different amount of transition work, and the cheapest-looking option is frequently the most expensive once the transition is planned. Retaining a service costs little in the moment but preserves ambiguity about its owner. Changing a service may be the right answer when the outcome is needed but the design is wrong. Combining services is attractive on paper and difficult in practice, because the combined service has to meet the needs of every constituency that used the originals. Retiring a service is the most visible decision and the one most likely to fail if users were not consulted about the route they will take afterwards.

A useful discipline is to write the target state first. Describe the service that will exist after the decision, its owner, its requesters and its fulfilment route. Then list what must change for users, records, reports and support to reach that state. If the list is long, the decision may be sound but the timeline should be longer than the enthusiasm for it suggests.

Sequencing a retirement so that no one is left without a route

Retirement tends to go wrong at the edges. The catalog entry is removed on the planned date, but the knowledge article still points to it, a scheduled report still reads its records, and a team that handled its requests has not been told the work has moved. A practical sequence starts with a notice period for users, moves on to redirecting new requests, then closes the old route once open items are cleared, and finally archives records in line with retention obligations. Each step should have an owner and a confirmation that it has happened, not only a date.

Open items deserve particular care. A request that was raised before the change still belongs to someone, and the review should decide whether it is completed on the old route, transferred or closed with a message. Leaving open items on a retired service creates a shadow queue that nobody watches.

The message to users deserves the same care as the technical sequence. A notice that says a service is changing, without naming the replacement route, produces a burst of calls to the service desk in the final week. A better notice names the old route, the new route, the date the change takes effect, the reason for it and the person to contact for a case that does not fit. Support teams should receive the same notice in advance and a short set of answers to the questions they expect, so that the first users to call do not receive different answers from different people.

Can a service be retired if a regulator refers to it?

Not without checking. A service that appears in a regulatory or contractual description may need to remain available in some form, or its replacement may need to be recorded as the same obligation. The legal and compliance owner should confirm the position before the decision is finalized.

Who should have the final say on combining two services?

The owner who will be accountable for the combined service should decide, after hearing from the owners of both originals. A decision taken by a committee with no accountable owner tends to produce a combined service that nobody runs well.

How long should a notice period be?

It depends on how often users rely on the service and how long the replacement takes to become familiar. There is no universal figure. The notice should be long enough that a user with an infrequent need will still hear about the change before they next require the service.

What if the service has no clear owner?

That is itself the finding. Assign an interim owner with authority to decide, and treat the rationalization as the process that resolves ownership before any other change is made.

Starting a rationalization without starting a dispute

Begin with one service that has visibly overlapping routes, and agree the decision criteria with the owners before any data is shared. Ask each owner what the service is for, who it serves and what would break if it stopped. Those three answers usually resolve the easiest cases quickly and expose the hard ones. For related reading, the strategic IT roadmap development page describes aligning ServiceNow investments with business objectives, and the CSDM service modeling page describes a shared way to say what a service is, who owns it and what it depends on. Where the catalog entries themselves need changing, the change, request and service catalog management page describes request and catalog management with clear routes. If a specific service is caught between owners, settle the decision and the transition plan before anyone changes a catalog item.

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

Related guides

More in this section