Why ServiceNow Projects Stall in Year Two
Year one of a ServiceNow engagement is, for most organisations, the easy part. There is energy behind it. There is a project team. There is a delivery partner with a plan and a go-live date. Progress is visible and measurable — milestones, releases, modules live.
Then year two arrives. The project team disperses. The delivery partner moves on to the next statement of work. The platform is running, but nobody is steering it. Requests pile up in a backlog nobody is managing strategically. The roadmap that looked clear at kickoff sits in a document that nobody is updating. And somewhere in a steering committee, someone asks why the platform is not delivering what was promised.
This is the ServiceNow year-two stall. It is one of the most common and costly patterns in enterprise technology — and it is almost entirely preventable. Not by working harder in year one, but by building the right structures before year one even begins.
The Stall Is Not a Year-Two Problem
The most important thing to understand about why ServiceNow platforms stall is that the stall does not originate in year two. It originates in the delivery model decisions made before the project started.
Year-two stall is what happens when a set of structural conditions — the absence of architectural continuity, the absence of outcome accountability, the absence of a governance mechanism that outlasts the initial delivery — encounter the reality that momentum eventually runs out.
Go-live is not the end of a project. It is the moment when sustaining the platform becomes harder than building it. And most delivery models are designed to get to go-live, not to govern what comes after.
The signs are rarely dramatic. They accumulate quietly, over months, until the frustration becomes impossible to ignore. The platform is running. But it is not improving. It is not measurably closer to the business outcomes it was built to deliver. And nobody can say precisely why — because nobody was accountable for the compound result from the start.
Four Structural Causes of the Year-Two Stall
Understanding the stall requires understanding its causes. There are four, and they are structural — which means adding more resources or running another project will not fix them.
1. The architect left at go-live.
In a standard pyramid model engagement, the architect — if there was a genuinely accountable one at all — was a scarce resource shared across multiple accounts. They shaped the early design decisions, appeared at key governance gates, and moved on. By year two, the person who held the original architectural intent has no active presence on the platform.
The consequence is that every new delivery decision — every new module, every integration, every configuration change — is made without reference to the platform's original architectural logic. Decisions that would have been caught by an architect who held the full picture pass through unchallenged. Technical debt accumulates. The platform becomes harder and more expensive to change with every release, quietly, until the roadmap stalls because the cost of moving forward has become too high.
Architectural coherence cannot be reviewed into existence at the end of a sprint. It has to be present continuously — which requires an architect who is actually there, not episodically consulted.
2. The roadmap was frozen at kickoff.
Most ServiceNow roadmaps are built at programme initiation and treated as a fixed plan. They reflect what the organisation understood about its needs at the beginning of the engagement — which is always the point at which its understanding is least mature.
By year two, the business has changed. Priorities have shifted. New capabilities exist on the platform that were not available when the roadmap was written. And the roadmap — if anyone is still consulting it — reflects none of this. It is a historical document, not a living instrument of direction.
The result is one of two equally dysfunctional patterns. Either the organisation continues executing against a roadmap that no longer reflects its actual priorities, burning delivery capacity on the wrong things. Or the roadmap is effectively abandoned and every request becomes a negotiation, with no strategic framework for prioritisation. Either way, year two becomes reactive rather than intentional.
3. Outcomes were never defined — or were defined and never measured.
Go-live is the moment when most delivery partners declare success. The modules are live. The agreed scope was delivered. The engagement, from the partner's perspective, is complete.
For the platform owner, go-live is when the real question begins: did this investment change how the business operates? And in most cases, the answer is that nobody knows — because success was never defined in business terms, and there is no measurement framework in place to find out.
ServiceNow outcomes governance — the discipline of defining what the platform is supposed to deliver in measurable business terms, instrumenting the platform to track it, and reviewing progress against it in a standing governance cycle — is the mechanism that should answer this question continuously. Without it, the platform runs. Value is asserted rather than demonstrated. And when the CFO asks at renewal what the investment has produced, nobody can answer in their language.
4. Adoption was left to the client after handover.
A module going live and a module being adopted are not the same thing. Most delivery models treat the former as their responsibility and the latter as the client's problem. Platform champions were not embedded. Role-based training was not structured around real workflows. The change impact was not mapped by department before deployment.
By year two, low adoption has compounded. Workarounds have developed. Users have found other ways to accomplish the tasks the platform was supposed to handle. And the business case for the next phase of investment is undermined by the fact that the previous phase is visibly underperforming in daily use.
