The cause for every failed ServiceNow implementation or project is often called “Scope Creep”. Why? Because of timeline overruns, budget blowouts, and then there’s stakeholder misalignment. These are the diagnoses that appear in retrospectives, project closure reports, and, with varying degrees of transparency, the final conversations between delivery leads and disappointed sponsors. They are not exactly wrong, but they are not the entire cause either.
They are the consequence – the real failure happened often weeks earlier, in a discovery workshop where a Business Analyst dutifully filled a confluence page with bullet points and called it requirements, or in a stakeholder interview where the process owner described what they wanted and no one asked why, or in a sprint planning session where assumptions were treated as decisions because there was no time to challenge them.
What gets called scope creep is, most of the time, a vocabulary problem. It is the name given to requirements that existed all along – real, operational, business-critical needs, but were never surfaced during discovery. Vague or incomplete initial requirements create interpretation gaps that stakeholders fill with their own assumptions. Those gaps widen in silence, then they explode during the build phase.
This article is an argument that most ServiceNow implementation failures are not platform failures, process failures, or even resourcing failures. Rather, they are requirements failures, and they are preventable – if the BA in the room is doing analysis, not administration.
The Anatomy of a Discovery Failure in ServiceNow Implementations
Discovery is where implementation fate is decided, and yet it is routinely under-resourced, compressed, and in some organizations, it is treated as a formality that must be completed before the real work begins. This framing is precisely the problem.
Stakeholders Describe Outputs, Not Problems
When a process owner walks into a discovery workshop, they bring with them a mental model of what they want. That model is almost always expressed in terms of output: “We need a form for this.” “We need an approval workflow here.” “Can we automate the notification?”
These are not requirements – they are solution hypotheses dressed up as requirements, and a BA who documents them without interrogation has just built the wrong thing on a solid foundation. The underlying problem and the actual reason behind the request are rarely in the first answer. It surfaces under questioning, and that questioning is the BA’s primary professional responsibility.
The Narrowness of the Room
Requirements gathered only from senior stakeholders are usually structurally incomplete. Senior stakeholders define intent, process owners know complexity, and end users know reality. All three perspectives are required for a coherent requirements picture, and most implementations collect only the first.
Designing a business solution before all end users have provided input frequently results in changes to plans and specifications because those users have different operational needs depending on their roles.
Workshops Treated as Tick-Box Exercises
The ServiceNow community has documented this pattern with uncomfortable clarity. As one practitioner account on the ServiceNow Community describes it: limiting time for requirements gathering gets the project moving quickly, but it slows down later, when a question requires another team for clarification and issues nobody knew existed surface, then you are applying band-aid solutions to wounds that need surgery because there would be no time to treat the actual problem.
Rushed discovery does not save time. It reallocates it from the front end, where changes are cheap, to the build phase, where they are expensive.
Why ServiceNow Makes This Uniquely Consequential
For every platform, there is always a price to pay for poor requirements. ServiceNow’s cost is high, and the reason is always architectural.
ServiceNow is a configuration-first platform of extraordinary flexibility. Its strength is that it bends to the organization’s needs. Its danger, which is rarely stated plainly enough in delivery conversations, is that it bends with equal fidelity to both good requirements and bad ones.
The platform has no inherent opinion about whether the process it is being asked to encode is sound. It will build exactly what it is told, and what it builds cascades through every subsequent sprint. A workflow designed in Week 2 to address a broken process is not a draft – it is a foundation, and everything built on it will inherit those flaws.
This is the dynamic that senior BAs know intimately because they have lived through late-stage reworks. A form with the wrong fields, a workflow designed to mirror a process that nobody actually follows, an approval chain that replicates organizational politics rather than operational logic. These decisions, made with incomplete requirements in early sprints, do not just affect the feature in question – they constrain every integration, every downstream workflow, every future enhancement.
Most ServiceNow failures are not caused by the platform itself – they happen because organizations underestimate the complexity of enterprise transformation. That underestimation begins at discovery, and it is the BA who should be the first line of defence against it.
The Clearwork process discovery guide also frames this precisely: discovery is no longer a phase you “get through.” It is a foundation you build on. The main risk in any ServiceNow transformation is automating assumptions. Discovery that happens in a rigorous, structured, contested way is what prevents that from happening.
The Gap Between What Stakeholders “Asked For” and What They “Actually Need”
This is the intellectual centre of the problem, and it deserves to be plainly stated: stakeholders rarely know what they need when they first walk into a discovery session. This is not a criticism – it is a structural reality of how human beings relate to process change.
The Psychology of Stated Requirements
Stakeholders always describe symptoms, not root causes. They tend to anchor on familiar tools and current workarounds. They describe the world they know and often “just replicate what we do in the spreadsheet”, rather than the world they need. They will tell you what frustrates them, but not what is causing the frustration, and they frequently do not know what they want until they have seen, clearly, what they do not want.
Business users typically know only their own job and cannot suggest process improvement on their own – that analytical work is the BA’s responsibility. Users know the current state. The BA must translate that into the future state.
The As-Is/To-Be Gap Is Not a Formality
The as-is process is not just documentation housekeeping – it is diagnostic, and it is the map that reveals where the real problems are hiding – the bottlenecks, the workarounds, the legacy decisions that became permanent by inaction. Without it, the to-be state is guesswork wearing the costume of requirements.
The BA’s discovery role includes identifying the gaps between what stakeholders say about the planned product and their actual expectations. This is not passive note-taking – it is an active gap analysis between stated intent and real operational need.
The BA’s job in this is to translate intent, not transcribe requests. Those are fundamentally different professional acts, and the distance between them is where ServiceNow implementations succeed or fail. “Stakeholders describe the process they have. Business analysts are responsible for designing the process they need. These are rarely the same conversation.”
The BA Habits That Catch Problems Before Build
What follows is not a methodology. It is a set of professional habits that distinguish BAs who prevent failures from BAs who document them. Senior practitioners will recognise all of these. The question is which ones are non-negotiable in their practice.
1. Challenging the Brief: Asking Why Before Documenting What
The most important word in a BA’s vocabulary is not “what.” It is “why.” Every stated requirement should be interrogated before it is written down. Why is this needed? What happens if it isn’t built? Who else is affected by this process? What is being done today, and why is that insufficient?
BAsA bridge the gap between development and business stakeholders, using data to assess processes, determine requirements, and deliver recommendations. The operative word is “assess.” Not record, not relay, assess!
The BA who asks the inconvenient question in Week 1 saves the project in Week 8. The BA who accepts the first answer at face value is not doing business analysis – they are performing secretarial work in a discovery setting.
2. Mapping As-Is Before Defining To-Be
No to-be design should be agreed upon before the as-is state is fully mapped and understood. This is not a bureaucratic process – it is an analytical discipline. The as-is map is the source of truth about what the organization actually does as opposed to what it thinks it does. The gap between those two things is consistently where the most important requirements are hiding.
The as-is process map provides answers to what can be improved, documents processes for compliance and training purposes, and establishes the basis for understanding requirements for process improvement. It represents what happens, not what should happen, or could happen, or the official procedure version of what happens.
3. Building the Right Room
Discovery workshops that include only senior stakeholders and product owners are structurally incomplete. The people who know the process most intimately, the ones who live in it daily, who have built the workarounds, who know which steps are broken, are process owners and end users, and they must be in the discovery room.
The BA’s goal is to identify the actual needs and translate them into business and technical requirements, not to relay the declared preferences of the most senior person who attended the kick-off call.
Structured, facilitated workshops with the right participants and with prepared questions, defined objectives, and disciplined follow-up are the environment in which real requirements emerge.
The ‘tell me a story’ induced style allows participants to explain in their own terms what the user experience actually is and consistently surfaces process dimensions that structured questionnaires miss entirely. The “tell me a story” style allows participants to explain in their own terms what the user experience actually is and consistently surfaces process dimensions that structured questionnaires miss entirely.
4. Writing Testable Acceptance Criteria at Discovery
Acceptance criteria written during sprint planning are too late. By that point, assumptions have already been baked into the backlog and decisions have been made. The conversation about what “done” means should happen at discovery while there is still time and space to challenge the brief, not just refine the story. Every story’s business value should always be challengeable, and acceptance criteria must use a consistent format.
Every story’s business value should be challengeable, and acceptance criteria should follow a consistent structure.
Quality story writing accelerates delivery because it removes ambiguity early, aligns to out-of-the-box ServiceNow patterns, and makes acceptance criteria testable across roles. Teams that invest here reduce rework, tighten sprint predictability, and protect upgrade outcomes.
5. Flagging Assumptions as Risks Before Sign-Off
Every requirements document contains assumptions. The professional discipline is to make them explicit rather than invisible. An assumption treated as a decision becomes a risk. A risk that is named and documented can be managed, but a risk that is buried in a bullet point becomes a rework ticket three sprints later.
Strong BAs maintain an active assumptions log throughout discovery – flagging where the as-is analysis is incomplete, where stakeholder input is conflicting, where platform capability may not match the stated requirement without customization. These flags are not failures – they are the BA performing their highest-value function: protecting the project from what it does not yet know.
What Delivery Leads Must Protect in a ServiceNow Implementation
This section is addressed to the delivery lead in the room. The person who controls the timeline, owns the budget conversation, and decides how much time discovery gets.
Here is the truth that every experienced delivery lead knows but does not always act on: every hour cut from discovery is borrowed, not saved. It will be repaid with interest in rework, change requests, escalations, and the particular pain of explaining to a senior stakeholder why the workflow they signed off on does not actually match how their team works.
A BA with compressed discovery time cannot do business analysis. They can take notes and produce a requirements document that looks complete, but they cannot challenge, interrogate, map, validate, or surface the assumptions that will become the project’s liabilities.
Without clear, measurable implementation objectives established at discovery, the project becomes unfocused, and this lack of clarity leads to scope expansion that later gets called creep.
Three things BAs need from delivery leads, and cannot create for themselves:
- Time: Enough to go beyond the first answer, map the as-is, and validate the to-be.
- Access: To process owners and end users, not just the project sponsor.
- Authority: To challenge, push back, and name assumptions as risks without being managed into silence.
The delivery lead who protects these conditions is not slowing the project down. They are front-loading the intelligence that makes everything after it go faster.
The Discipline of Pre-Build Clarity
Great ServiceNow implementations are not ultimately a function of the platform. They are a function of what was understood before anyone touched a configuration screen. The platform is the instrument, requirements are the score, and no instrument, however powerful, compensates for a score that was written in haste.
The BA who asks the inconvenient question in Week 1, who refuses to accept the first answer, who maps what is before defining what should be, who writes testable criteria before a single story enters a sprint – that BA is not creating friction, they are creating insurance. They are the practitioner who makes the difference between a ServiceNow implementation that delivers and one that delays.
Scope creep is the symptom. Poor discovery is the disease, and the cure is not a methodology, a governance framework, or a new project management tool. The cure is a BA with the professional confidence to challenge what they hear, analyze what they see, and document not just what stakeholders want but what the organization actually needs.
The BA is not the person who takes notes in discovery. The BA is the person who prevents the project from building the wrong thing brilliantly.
In every ServiceNow implementation, there is a moment, usually in discovery, where the project’s fate is decided. It rarely looks like a critical decision – it looks like a workshop, a conversation, a BA with a laptop and a list of questions. That BA is either asking the right ones, or they are not. Everything else flows from that.