OBLYTECH Logo
Enquire Now
OBLYTECH Logo

OBLYTECH / ServiceNow

Navigating ServiceNow Implementation Pitfalls: A Comprehensive Guide 

Moving to ServiceNow is rarely as simple as the demo suggests. These eight steps address the problems that most often derail an implementation.

For readers evaluating this topic and deciding what to review next.

ServiceNow implementationServiceNowpractical guide
Discuss this topic

Guide map

A practical framework for servicenow implementation.

Define the question and scope

Write down the problem the implementation must solve and where it stops.

Make decisions and ownership visible

Name the owner of each decision, so open questions do not stall unnoticed.

Review evidence and next actions

Check each decision against the evidence before the next phase begins.

The practical framework

Most ServiceNow migrations hit the same few snags. This guide walks through eight steps that keep the project on track from planning through to a clean handover.

Step 1: Define and Measure Business Goals 

Start by stating your goals and vision in unambiguous terms. To monitor and evaluate performance and make sure it is in line with your strategic goals, set up clear metrics. 

Step 2: Secure an Executive Sponsor 

Choose an executive sponsor who is committed to the project and will be involved all the way through to completion. Their backing is essential to spearheading the project and obtaining required funding. 

Step 3: Engage Experienced ServiceNow Experts 

Make sure you have access to qualified and seasoned ServiceNow experts. Their knowledge is essential for understanding the intricacies of the platform and making the most of it. 

Step 4: Adopt a Phased Approach

Consider implementing your plan in stages. This stepwise approach guarantees consistent growth and aids in risk management. To find possible problems in a controlled setting, conduct pilot tests. To make sure everything goes according to plan, test the migration procedure using a small sample of data. Utilize this stage's feedback to make the necessary modifications. 

Step 5: Establish a Strong Foundation 

Give priority to out-of-the-box (OOTB) features in order to make the most of built-in capabilities. Analyze your options carefully for architecture and map basic processes to match your business requirements. 

Step 6: Train Your Teams 

Create a thorough training program for your personnel responsible for implementation and maintenance. Sufficient training is essential for smooth functioning and sustained achievement. 

Step 7: Implement Value-Driven Governance 

Establish a governance framework to aid in the execution of your plan. Create a distinct ServiceNow operational model to efficiently direct technical and business choices. 

Step 8: Develop Change Management and Communication Plans 

Create all-encompassing communication and change management methods. Encourage an advocacy-focused culture to promote adoption and ongoing development. It takes ongoing observation to quickly resolve any post-migration problems. Provide a support system to address user inquiries and technical issues. Assess system performance on a regular basis and make the required adjustments. 

Common questions

Questions teams ask about servicenow implementation

What should a review establish first?

Start with the question, scope, decision boundary, ownership, and evidence that the reader needs to carry into the next action.

How should the next action be chosen?

Use the article framework to identify the unresolved decision, the responsible group, and the record that will show what happened.

The documented boundary

This article is presented as a practical reference. Apply its recommendations against the specific systems, responsibilities, and evidence available in the organization being reviewed.

Customize Only After a Keep, Configure or Retire Review

Much implementation trouble starts when a team copies the way the old process worked into the new platform. Each legacy step gets a matching flow, a custom table, a form field and an approval, and the result reproduces every workaround the organization already had. A better habit is to review each requirement before design begins and sort it into one of three groups: keep the platform behavior as shipped, configure a standard capability with local settings, or retire the step because the business no longer needs it. Only the first two groups should reach the build backlog.

Question about the requirementIf the answer is yesIf the answer is no
Does a standard table or workflow already hold this data or route this work?Configure the standard capability and record the settingMove to the next question
Is the step required by a control, audit or contract?Keep it, and name the control owner who will test itMove to the next question
Does the step serve a current decision that someone can name?Design it as a scoped change with a named ownerRetire it and record the decision

The test is deliberately blunt. A requirement that cannot name a decision, a control or an owner is usually a habit, and habits are expensive to carry through upgrades and regression testing. For OBLYTECH’s implementation work as a whole, see the ServiceNow implementation services page.

Settle the Data Before Building the Process Logic

Teams often start with forms and approvals because sponsors can see them. The risk is that the logic then sits on records that do not yet agree with each other. Migration mapping, reference data for categories and groups, and the source of truth for users and locations need to be stable first. Until they are, every flow tested against them will need rework. A workable order is to fix the reference data, load a representative sample, reconcile it against the source system, and only then build the workflows that depend on it. The validation and cutover guide covers validating migrated data before cutover, and the migration reconciliation and cutover page covers data migration with reconciliation evidence.

  1. Agree the authoritative source for users, groups, locations and services, and write down which system wins when two disagree.
  2. Map every legacy field to a platform field or mark it as retired, recording the person who approved each mapping.
  3. Load a sample that includes the awkward records: inactive users, shared mailboxes, duplicate locations and records with no owner.
  4. Reconcile record counts and spot-check a set of records against the source before any workflow is tested.
  5. Build the workflows, then test them against migrated data rather than tidy test records.
  6. Promote through the agreed release path and confirm that production matches what was tested.

The Pitfalls That Surface in the First Weeks After Launch

Several of the problems that appear after launch were visible much earlier. Access is a frequent one. Roles are granted broadly during build so testers are never blocked, and the broad grants are never removed. Access control lists then stop matching the work each person does, and the first audit finds the gap. A second pattern is the catalog that grew by copying old forms. Each item carries its own variables, approval and notification, so requesters cannot tell which one to pick. A third is an integration built against a test endpoint with a service account holding administrator rights, which later has to be replaced under pressure.

Two smaller failures recur. Business rules get added to fix one reported defect and then conflict with a later rule, which is hard to trace without a change record. The business rule governance guide covers keeping business-rule logic understandable, bounded, tested and owned. And training is scheduled for the week before launch instead of being built around the roles that will use each screen.

Signs the Implementation Is Working, Not Merely Launched

A go-live date is a poor measure of success. A better check is whether the people who use the platform finish their main tasks without support, whether the records they create are complete enough for the next team to act on, and whether the number of manual exceptions is falling. Track why tickets are reopened or reassigned, because those reasons point to design gaps rather than user error. If the same workaround appears in three teams, treat it as a requirement that was missed. Ownership of those decisions is easier to hold when a platform governance charter, such as the one discussed in the platform governance guide, defines who decides about access, data, applications and exceptions in advance.

When a Requirement Should Be Declined Outright

Some requests should be turned down at the design stage. A feature that serves one team’s preference, duplicates a standard capability, or depends on data nobody maintains will create more work than it saves. Declining is easier when the decision record names the alternative: what the team can do instead, when the request can be reviewed again, and what evidence would change the answer. That record stops the design being reopened every time a senior person asks for something new.

Should we customize the platform before users have been trained?

Usually not. Customization built before users have worked through the standard process tends to encode guesses about how they will behave. Run the standard workflow with a small group, record where they stop, and change only the steps the evidence supports.

How many admin roles should a delivery team hold during build?

Give each team the access its tasks need and review it at every release. Keep the people who change configuration separate from the people who approve it where the risk justifies the split, and keep a short, current list of who holds the highest privileges.

What is the practical difference between a scoped application and a global change?

A scoped application keeps its tables, logic and dependencies inside a defined boundary, which makes ownership and removal easier to manage. A global change touches shared behavior, so it needs a wider review and a rollback plan written before it is applied.

Who signs off that a migrated dataset is fit for use?

The business owner of each dataset signs off, using reconciliation results and spot checks. The implementation team prepares the evidence, but the owner decides whether the records are reliable enough to act on.

What should happen when a go-live milestone slips?

Establish whether the slip comes from unresolved scope, unstable data or a gap in testing. Move the date only when the cause is known and a recovery path is written down. A date moved without a cause usually reappears as a second slip.

Before the next release is locked, it is worth reviewing these build decisions against the questions above. To discuss an implementation, contact OBLYTECH.

Why ServiceNow implementations fail, and a defect routine that keeps the project moving

Implementations rarely fail because of one dramatic mistake. They fail because small decisions are left open until they become expensive: nobody owns a process, a customisation replaces a setting that already existed, or test results are collected after the date everyone had agreed to go live. The pattern is easier to prevent than to repair.

Common causes behind a troubled go-live

  • Scope that grows by agreement in meetings and is never written down, so the plan stops matching the work.
  • Custom code written for a requirement that standard configuration would have met, which later makes upgrades harder.
  • Imported data that was never cleaned, so incident, asset and configuration records arrive already wrong.
  • No named process owner on the business side, which leaves every design question waiting for an answer.
  • Testing planned as a final phase instead of running alongside each build cycle.

For a service desk project the same list applies on a smaller scale. Start with incident, request and knowledge, prove them with real users, and add other processes once the first group is stable.

A defect routine that works in practice

Give every issue found in testing one of four labels: a build defect (the system does not do what was agreed), a requirement gap (it does what was agreed, but the agreement was wrong), a data problem, or a change request (new scope). Each label has a different owner and a different cost, so mixing them hides how healthy the project really is.

Hold a short triage meeting on a fixed rhythm, assign severity by business impact, and set a clear rule for what blocks go-live. Fix defects in order of that impact, record the retest result next to the original defect, and close an item only when someone other than the person who fixed it has confirmed the result. Change requests go on a separate list that the sponsor reviews, so scope stays visible.

If you want an outside view before committing to a plan, an assessment of readiness checks ownership, data and scope early. Decision rights after go-live are set out under platform operating model and governance, and the delivery work itself is described on the ServiceNow implementation page.

A first service desk release: what to include and what to hold back

For most organisations the first service desk release should cover incident intake, assignment and a short list of requests that already have a named owner. Hold back problem management, automated change approvals and custom reporting until the incident process has run for several weeks. Extra categories add routing rules, training and testing, and that is a common reason a service desk go-live slips.

The test for each item is simple. A feature belongs in the first release when the team can name the person who acts on it and the process it follows today. If either answer is missing, the item is a design question, not a build task.

ItemInclude in the first release whenHold back when
Incident intake and assignmentEach queue has a group lead who reviews it dailyRouting depends on rules nobody has written down
Standard service requestsThe fulfilment steps are the same every timeEach request needs a different approval path
Change approvalsThe current approval steps are already followed in practiceThe approvers have not agreed who signs off what
Problem recordsRepeat incidents already have an ownerThe incident data is still being cleaned
Custom dashboardsThe team can name the decision each one supportsThe figures are still being argued about

Keep the training and the cutover plan in step with the scope. A smaller release is easier to train, easier to test and easier to roll back, and it gives the team a stable process before the next wave. The service operations design is where to set the baseline for queues and groups before any of these items are added.

Plan the problem and major incident process as a second release. Those processes depend on clean incident history, and a team that has not yet run several weeks of routed incidents may not have the data to judge a problem trend. Set a date for that review, and move the item into scope only when the incident and problem design has been agreed with the people who will run it.

Build the training and adoption plan around the exact queues and request types in scope, not the full target design. Agents only need to handle what they will see that week, and a shorter training list is one they will remember on the day.

Go-Live Decision Rules for a ServiceNow Implementation: What Must Be Closed First

A go-live decision should rest on a short list of conditions written down before final testing starts, not on how close the date is. In most implementations that list covers three things: the open build defects left at each severity, the reconciliation result for every migrated dataset, and a rollback path the team has rehearsed at least once. If one of the three is missing, the answer is not yes yet, whatever the calendar says.

Read the defect list differently at this stage. The question is no longer whether each defect is fixed. It is whether any open item stops a person finishing their main task on day one. A cosmetic fault on a rarely used form can go live with a known workaround and a dated fix. A failed approval on a request type that many people raise cannot. Write the workaround beside each open item, so the sponsor sees what users will actually do. Who signs off each fix is covered in the guide to business-owned UAT planning, which sets up this decision.

Data needs its own sign-off. Someone outside the implementation team should confirm the figures before go-live. A matching count can still hide wrong owners or wrong locations, so the owner should test the sample against the cases that tend to break, not only the totals.

Rollback is the step teams most often skip. Decide in advance what reverting means for each change: which configuration can be switched off, which imported records can be removed, and which integrations must be paused so they do not write back to the source system during the revert. Rehearse that path in a non-production copy. A rollback that has never been run usually takes longer than the window allowed for it.

Hypercare needs a named owner for each queue and a fixed daily review for the first two weeks. Agree the triggers before go-live, such as a rising count of reopened records or a queue nobody is clearing, and write down who can call a pause. Whether that support is handled internally or by an outside team after launch is a separate choice, covered in consulting or managed support.

  • Open defects with workarounds, listed by severity
  • Reconciled data signed off by each business owner
  • A rehearsed rollback path for each change
  • Named hypercare owners and a daily review

ServiceNow Implementation Challenges in Regulated Organizations and How to Spot a Failing Project Early

Many of the most common ServiceNow implementation challenges are not technical. They are unclear ownership, evidence nobody can produce at audit time, and a scope that grows faster than the people who must test it. In a regulated organization such as a bank, insurer or health provider, each of these also carries a compliance cost, so a project that looks merely late can already be failing.

The warning signs usually show up weeks before a missed date. Look for these:

  • Nobody on the business side can say who approves a change to a form, a workflow or a role.
  • Test results live in personal spreadsheets or chat threads rather than in one place an auditor could read.
  • The open defect list grows every sprint while the closed list barely moves.

Two or more of these together usually mean the plan needs a reset, not more effort. In most implementations a reset means freezing new scope and naming an owner for every open decision.

Rescue or restart: a simple decision rule

Keep the build if the data model, the access design and the integration approach are sound, and the problem is process and ownership. Restart the affected area if people copied old customizations in without review, if roles were granted so broadly that nobody can describe them, or if the build cannot be tested without developer help.

For regulated work, add one more test. For each control the business must show, ask whether a person outside the delivery team could find the evidence in under an hour. If not, fix the evidence trail before adding features. A well-run change management advisory engagement or an internal equivalent often starts exactly there, with decision rights and approval records.

What a recovery plan should contain

  • A short list of what goes live first, with everything else explicitly parked.
  • One named business owner and one named technical owner per process.
  • A review of performance and upgrade risk before go-live, as covered under performance tuning and upgrades.

If the team cannot agree on the first release, an outside assessment through ServiceNow consulting can give a written view of what is sound.

Name the Platform Owner Before the Implementation Team Leaves the Site

The platform owner is one named person who decides which changes enter the instance after go-live, and that decision has to be made before the project team steps back. Where nobody holds the role, requests reach administrators through email and chat, fixes get made straight in production, and the configuration drifts away from the design the project approved. The first sign is usually a change that nobody can explain six weeks later.

The role is narrower than a project manager’s and wider than an administrator’s. The owner keeps one intake route for every change request, decides whether each request is a configuration setting, a scoped change or a refusal, and keeps a current register of which person owns each scoped application and each custom table. That register is easy to skip at handover. It takes little time to write and helps most when the first incident arrives.

A workable handover runs in four steps:

  • Name the owner and give them written authority to decline requests, before go-live rather than after.
  • Move every open defect and enhancement into one queue that the owner reviews on a fixed day each week.
  • Agree a release calendar, so that change governance and release management happen in predictable windows instead of whenever someone needs a fix.
  • Make the owner the only person who requests elevated roles for the team, so every access change leaves a trail.

The common failure is the emergency fix. An approval rule needs changing on a Monday morning, an administrator corrects it directly, and the change never reaches the design record. The next release can then overwrite it or conflict with it, and the team spends time working out why. The fix itself is rarely the mistake. The mistake is that the owner never heard about it.

Once the platform is stable, the owner also decides where the next round of improvement comes from. Requests that arrive repeatedly from the same teams usually point to a process that was designed too narrowly at the start, and they are worth grouping before anyone builds anything. Planned work of that kind is what ServiceNow optimization and enhancement covers once the first release has settled.

A practical next step

Need a clearer operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. Use the OBLYTECH contact route to start the conversation.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

Explore OBLYTECH services

More from the blog

Related reading