Phase one gets decided in the first six weeks
Whether a ServiceNow ITSM programme lands is settled long before anyone opens a development instance. It gets settled in the weeks when someone writes down what phase one contains, who owns the records that will fill it, and what the organisation agrees to stop doing on the day it goes live. Careful engineering delivering the wrong thing on time is a scoping failure, never a build failure.
The earliest warning sign is a scope written in module names. Incident, request, change, knowledge and the CMDB in five months looks complete on a steering slide and says nothing about what anyone will be able to do in month seven that they cannot do today. Module names describe what you bought. They do not describe what changes.
So ask for outcomes with a name attached. The service desk manager can see every open ticket for a business service on one list. The change manager can approve a standard change without a meeting. The finance business partner gets a monthly cost per service without asking anyone. Each pulls specific configuration and specific data behind it, and each can be tested by the person who asked for it. A ServiceNow ITSM scope built that way survives a steering committee, because every line has somebody who will notice if it disappears.
Incident, request and change are three programmes
They share a platform and a release train, so plans keep folding them into one workstream with one set of workshops. The owners are different people, the data behind each comes from somewhere different, and the definition of done for each lands in a different part of the business.
Change work lands with the approval board, the maintenance calendar and whoever signs off risk. Request work lands in catalogue items owned by fulfilment groups in facilities, HR and procurement, most of whom have never touched the platform. Incident work lands with the service desk, the priority matrix and the major incident bridge. A phase one that works usually carries incident and request with a service model underneath, then puts change into a second release eight to twelve weeks later.
The second failure grows out of the first. Each process owner designs their part in their own workshops, everyone signs off, and the handoffs do not meet. On one programme the incident owner had assumed a failed change would raise an incident automatically with the change number on it. The change owner had designed a post-implementation review that recorded the failure and closed. Nobody was wrong inside their own design document. The record simply stopped at the boundary.
The cheapest fix is one session per handoff with both owners present, walking a single record across the line and saying out loud what should exist on the other side. Failed change to incident. Breached request to incident. Repeat incident to problem. Catalogue item to a fulfilment task in a team that does not use ServiceNow. That last one is where the service catalogue becomes an operating contract rather than a list of things people can ask for.
Modernizing an old instance is a different job
The programme that taught me most was at a utilities company of about four thousand staff, modernizing an instance live since 2016. The brief said modernization. What the sponsor wanted was an exit from maintenance, because the upgrade path had stalled two releases back and the platform team spent most of its capacity keeping old customization working.
A first implementation argues about how the process should run. A modernization argues about which parts of nine years of configuration survive, and that argument has different people in it. We counted three hundred and forty business rules, ninety of them on the incident table, and about half had no named owner. Every one had been requested by somebody who believed the platform could not work without it.
A modernization scope without a retirement decision against each piece of existing configuration is not a scope. Modernization needs a retirement list carrying keep, rebuild or drop for every item, plus a named person who will defend the drops when the requester objects in month four. Ours took until week five and removed more from the plan than the workshops added.
Somebody owns the data before it arrives
Pushing the CMDB into a later phase is the most expensive move I see in ITSM scoping, and it happens because the CMDB is the hardest part and the date is already fixed. The deferral looks sensible in the plan. Then the outcomes that justified the programme turn out to sit on it.
Change impact needs service relationships. Major incident triage needs to know what a failing host supports. Routing by service needs a service definition somebody maintains. Cost and availability reporting needs the same. Defer the CMDB and you keep the ticket tool while losing the reason you replaced the old one. Getting a CMDB into shape before anything reads it is slow work, which is why it belongs inside phase one rather than after it.
Data ownership is a separate question from data source. Users and groups usually arrive from an identity directory, service definitions from architecture, asset records from procurement, location data from facilities. For each one, write down a name, a delivery date and the format. A source with no owner becomes the platform team's problem during user acceptance testing, and that team has no authority to decide whether a cost centre is correct.
Count the integrations before you agree a date
At the utilities company the go-live date reached the steering pack before anyone had a list of interfaces. When we finally built it, the list held thirty-one entries. Eleven were one-way feeds nobody argued about. Four were bidirectional ticket exchanges with outsourced suppliers, each with its own contract, its own field mapping and a test window governed by the supplier's change process rather than ours.
Those four moved the date by fourteen weeks, and none of it was build effort. It was waiting for other organisations to schedule testing. No amount of platform skill compresses that, and no sponsor enjoys hearing it in month three.
Build the integration map before the roadmap. One row per interface, with direction, owning team, the external party if there is one, and the earliest week they can test. Then set the date. A date agreed before that list exists is a number somebody made up, and everyone in the room works that out by the second steering meeting.
Write down what stops when this goes live
The last scoping question is usually missing from the document. Nobody records what the organisation stops doing on the day this lands. The old ticket tool, the shared mailbox facilities uses, the spreadsheet the network team keeps, the number printed on every laptop. With no closing date against any of that, you have replaced nothing and added a system.
At the utilities company the facilities team kept their shared mailbox for six months after go-live, because nobody had agreed a date to close it. Roughly two in five of their requests never reached the catalogue, so the volume report that went to the board was wrong by that much, and the phase two business case was built on it.
Before you sign a plan, put one page in front of the sponsor with three columns. The outcome. The person who owns the data behind it. The thing that stops on the day it lands. Any line missing a third column entry is not in phase one, whatever the module list says. That page is also the one worth reading again during the second week after go-live, when everyone finds out which promises the scope actually carried.
