PLAYBOOK
Two tracks, one arrival.
ServiceNow OCM Project Plan: The Framework That Determines Whether Your Implementation Succeeds or Stalls
📍 THE BLUF
By the end of this you will be able to run organisational change management as a governed workstream, with owners, deliverables and dates, sequenced so that human readiness and the technical build arrive together instead of colliding at go-live. The hard part is not the communications plan. It is deciding, before you write a word of it, who is accountable for adoption, and whether your sponsor will actually spend political capital to earn it.
When an implementation stalls after go-live, the diagnosis is rarely technical. The build works. People simply carry on as before, quietly routing around the platform they were given. The gap is not in the technology, it is in the readiness of the organisation to use it, and readiness is something you plan, resource and govern, or something you merely hope for.
London's Elizabeth line ran roughly twelve months of trial running before it carried a single fare-paying passenger, rehearsing scenarios and training operators until the people were as ready as the tunnels. It opened late and then ran reliably. Most platform programmes invert that order: they finish the build close to schedule and hand it to an organisation that has never once rehearsed the change.
You will have heard that some large majority of change programmes fail. Treat that figure as folklore. The number is contested, it varies with whoever is quoting it, and it tells you nothing about what to do on Monday. What the evidence does support is narrower and far more useful. The single strongest predictor of whether a change lands is active, visible sponsorship. By Prosci's benchmarking, sponsorship has topped the list of success contributors in every study for decades, cited more often than any other factor. That is where an OCM plan should start, not with a launch email.
When to use this
This is for platform owners and programme leads running a rollout large enough that adoption is not automatic. It assumes you have a delivery plan and a governance forum, however light. If OCM in your programme currently means a launch announcement and a training day booked by whoever had capacity, this is written for you. If you have no sponsor at all, stop and get one before you plan anything else. Everything that follows assumes you can.
Stage 1, secure a working sponsor before anything else
Get an active, visible sponsor first. Everything downstream leans on it.
The sponsor is not the person who opens the launch event and is never seen again. It is the person who sets the priority when two directors disagree, removes the obstacle that a project team cannot, and is visibly the first to change their own behaviour. Prosci's numbers are stark: a programme with a genuinely effective sponsor is far more likely to meet its objectives than one with a passive figurehead. An executive steering committee can supply that backing, but only if a single named individual owns it.
The gotcha: accepting a figurehead. A sponsor who lends their name but not their diary is worse than none, because their silence reads to the organisation as indifference. Test them once. Ask them to name the three behaviours they are asking people to change. If they cannot, you have a logo, not a sponsor.
✅ PRINCIPLE
The plan serves the sponsor, not the other way round. A brilliant communications plan cannot compensate for a sponsor who will not spend capital, whereas an active sponsor can carry a merely adequate plan. Resource accordingly.
Stage 2, map who the change actually lands on
Work out who loses something before you tell anyone what they gain.
A rollout never lands evenly. One group gains a faster route through their day. Another loses a familiar workaround, a measure of status, or a task they were comfortable owning. Stakeholder mapping is the input to everything that follows, because the group with the most to lose is the one whose quiet resistance will sink adoption while your dashboards still look healthy.
The gotcha: treating "the users" as one block. Averaged across everyone the change looks positive, so you brief everyone the same way. The people it costs hear a message written for the people it helps, and conclude that nobody understood their world.
Stage 3, build a change champion network inside the business
Recruit champions for influence, not availability.
Champions are respected peers embedded in the teams that have to change. They field the quiet questions a project team never hears, and they are your earliest signal that resistance is building somewhere. Recruit them during the mapping stage, give them the reasoning rather than just the script, and give them a direct line back to whoever owns the change.
The gotcha: staffing the network with whoever volunteered. Availability and influence are rarely the same people. A champion nobody on the team actually listens to is a distribution list wearing a lanyard.
Stage 4, sequence readiness to the build, not the calendar
Tie every change milestone to a technical one.
The commonest failure is the right activity at the wrong time. Communication that arrives so early people have forgotten it by launch. Training booked for a fixed date months out that lands before the thing it teaches exists, or after frustration has already set in. Sequence communication to begin as capability firms up, and training to land close enough to go-live that people retain it. When the build slips, the readiness plan slips with it.
The gotcha: a training calendar fixed in a planning spreadsheet and never revisited. Dates set for the convenience of the diary rather than the readiness of the audience guarantee that you teach people to use something that is not there yet.
The OCM workstream runs in lockstep with the build, not after it.
Stage 5, decide how you will know it worked before go-live
Define adoption measures up front, with a baseline and a target.
Agree what success looks like while you can still influence it: a baseline, a target, and a small set of leading indicators, such as training completion, sentiment and champion feedback, that move before the lagging ones like actual usage do. The point of measuring early is not the report. It is the chance to intervene while the launch is still recoverable.
The gotcha: defining success after launch. Wait until the platform is live and "adoption" quietly becomes whatever the numbers happen to allow, retrofitted into a story that sounds like a win. A measure you set before you knew the result is the only one anyone should trust.
Stage 6, run OCM as a governed workstream, not a status update
Give change the same governance as the build: owners, deliverables, dates.
Put OCM on the plan beside the technical workstreams, with named owners, dated deliverables and a seat in the same review where delivery is discussed. Clear team charters make that ownership explicit. When the programme reviews progress, human readiness should sit on the same page as technical readiness, so a gap in one is visible against the other rather than discovered in the week of go-live.
The gotcha: OCM owned by "the team". Ownership by everyone is ownership by no one. If no single name sits against adoption, it becomes the workstream that is always someone else's job, right up until go-live week, when it is suddenly everyone's emergency.
⚠️ COMMON PITFALL
The most expensive OCM mistake is bolting it on once the build is already scoped. By the time resistance surfaces at go-live it has calcified, and retrofitting adoption costs several times what sequencing it from the first planning session would have. Fund and plan change as a workstream from day one, or pay for it later at a premium.
🎯 QUICK WIN
Before your next steering meeting, ask your named sponsor to write down the three behaviours they want people to change. If they can, you have a real sponsor. If they cannot, you have found your biggest risk while there is still time to fix it.
📋 QUICK REFERENCE
The governed OCM workstream, in six moves.
Sponsor. Secure an active, visible sponsor who will spend capital. Everything else leans on this.
Map. Work out who the change costs, not just who it helps, before you message anyone.
Champions. Build a network of respected peers inside the business. Recruit for influence, not availability.
Sequence. Tie communication and training to technical milestones, not to fixed calendar dates.
Measure. Set the baseline, target and leading indicators before go-live, not after.
Govern. Run OCM as a workstream with named owners, dated deliverables, and a seat in the delivery review.
The bottom line
If you protect one thing, protect sponsorship. A governed workstream, a mapped audience, a champion network and honest measurement all matter, but they are amplifiers. An active, visible sponsor turns a decent plan into adoption. A passive one turns a perfect plan into a very well-organised way to fail. Get the sponsor right, then run the rest as the workstream it always should have been.
P.S. Before your next planning session, find the single name accountable for adoption. If the honest answer is a team, a committee, or a blank, that is not a gap in your documentation. It is your project's biggest risk, and you have just enough time to close it.