ServiceNow implementation plan: what should we do in the first 90 days (incident, request, change, CMDB foundations)?

The first 90 days of a ServiceNow implementation are not for “going live with everything.” They are for proving control. If incident, request, change, and CMDB are still fragmented at day 90, you have not implemented a workflow platform—you have installed another ticketing layer.

The right move is narrower and more disciplined: stabilize the highest-volume service work, define the operating model, and build a CMDB foundation that supports real decisions. That means one thing above all else: start with the workflows people touch every day, not the features that look impressive in a demo.

The short answer

In the first 90 days, focus on four outcomes:

Incident — route, prioritize, and resolve the most common and most painful issues faster.
Request — standardize the top service requests and make fulfillment predictable.
Change — put risk-based control around changes that can break the business.
CMDB — create a trusted, minimal, service-aware data foundation for those workflows.

Do not try to model every asset, automate every process, or redesign every team. Build the minimum viable operating model first. Then expand.

90-day implementation plan at a glance

Phase	Primary goal	What you should deliver	Exit criteria
Days 1-30	Define scope and governance	Process owners, RACI, baseline metrics, top use cases, CMDB scope, data sources	Everyone agrees what is in scope and how success will be measured
Days 31-60	Configure core workflows	Incident, request, change, and CMDB design; priority/routing rules; catalog items; change models	Core workflows are built and tested with real data
Days 61-90	Pilot, harden, and prove value	Pilot go-live, dashboards, training, data quality fixes, automation for standard work	You can show measurable improvements in speed, control, and data quality

Days 1-30: Define the operating model before you build

This is the “Sense” phase. Don’t start by configuring forms. Start by answering a few blunt questions:

What service problems hurt the business most?
Which teams own those problems?
What work must be controlled for audit, security, or compliance reasons?
Which data sources are trustworthy enough to anchor the first CMDB slice?
What does success look like in 90 days?

Lock the scope

Pick a small but meaningful launch scope. Good first scopes are usually:

One enterprise service desk
One or two business-critical services
The top incident categories by volume
The top request types by demand
A limited change population with clear risk

This is where many implementations fail. They try to cover IT, HR, security, customer service, and app dev at once. That is not scale. That is overload.

Assign ownership

Every workflow needs a real owner.

At minimum, define:

Executive sponsor
ITSM process owner
CMDB owner
Platform owner
Service owners
Fulfillment group leads
Change manager
Data steward

If no one owns the process, the platform will absorb the blame for weak governance.

Baseline the numbers

Before you change anything, capture current-state metrics:

Incident volume
MTTR
First assignment accuracy
Reassignment rate
Request fulfillment cycle time
Change success rate
Emergency change rate
CMDB completeness for critical services
CI relationship accuracy

If you don’t baseline first, every later improvement becomes a guess.

Define the minimum viable CMDB

Do not start with “all configuration items.” Start with the things that support incident, request, and change decisions.

For day 30, define:

Which business services matter
Which application services support them
Which critical infrastructure CIs are in scope
Which owners are required for each CI class
Which source systems will feed data
Which fields are mandatory

That is enough to build a foundation. It is not enough to claim the CMDB is “done.” That’s fine.

Days 31-60: Build the core workflows

This is the “Decide” and early “Act” phase. Configure the platform around how work really moves.

Incident: reduce noise and speed up resolution

Start with the top incident drivers. Not every issue. The biggest ones.

Build for:

Clear categorization
Priority rules
Assignment logic
Escalation paths
Major incident handling
Knowledge linkage
Swarming or resolver collaboration if needed

The goal is simple: route the right ticket to the right team fast, with enough context to act.

Focus on:

Top 10 incident categories
High-impact services
Reassignment reduction
Major incident communication
SLA tracking

If your incident process still depends on tribal knowledge, ServiceNow will only make the chaos visible faster.

Request: standardize the high-volume asks

Request fulfillment is where teams reclaim time.

Start with the most common request types:

Access requests
Software requests
Hardware requests
Standard employee service requests
Common service desk asks

For each one, define:

Catalog item
Fulfillment group
Required approvals
SLA
Fulfillment steps
Exceptions
Notifications

Do not build a catalog that looks complete but is too complicated to use. Start with the few requests that drive the most volume.

A good rule: if a request is repeated weekly, it belongs in the first 90-day scope.

Change: put control around risk, not around paperwork

Change management should not become a bureaucracy factory. It should reduce business risk.

Start with these basics:

Standard changes for repeatable, low-risk work
Normal changes for controlled review
Emergency changes for true exceptions only
Change calendar for visibility
Risk scoring based on service criticality and CI impact
Approval rules that match risk, not politics

This is where the CMDB matters. Change without service and CI context becomes guesswork.

Your goal is to answer:

What is changing?
What depends on it?
Who owns it?
How risky is it?
What is the rollback plan?

If the answer is unclear, the change should not be routine.

CMDB foundations: build a trusted slice, not a perfect model

The CMDB is not valuable because it is large. It is valuable because it is trusted.

In the first 90 days, build a CMDB foundation that supports operational decisions. That means focusing on quality over quantity.

What to include first

Start with:

Business services
Application services
Service owners
Critical servers and infrastructure
Key network dependencies
Databases and core applications where needed
Relationships between services and dependencies
Source-of-truth mappings

What to defer

Do not try to model everything on day one:

Every endpoint
Every printer
Every low-value peripheral
Every legacy shadow asset
Every optional relationship

That work can come later. First, make the CMDB useful for incident, request, and change.

What good CMDB foundations require

A usable CMDB needs:

Clear data ownership
Defined identification and reconciliation rules
Regular data quality checks
A limited number of authoritative sources
A simple lifecycle model
A practical relationship model

If you cannot trust the data, the workflow will not trust the data. Then adoption falls apart.

Days 61-90: Pilot, harden, and prove value

This is the “Act” and “Govern” phase. The platform should now be doing real work in a controlled pilot.

Go live with a small, real scope

Do not wait for perfection. Launch with:

One incident queue or service tower
One request catalog slice
One change process population
One CMDB service layer

Then measure what happens.

Tune the workflows based on real usage

Look for:

Misrouted incidents
Unused catalog items
Overly complex approvals
Change records missing CI links
Duplicate or stale CMDB records
Bottlenecks in fulfillment

Fix the friction fast. Adoption follows friction reduction.

Establish a governance cadence

At this stage, set a steady operating rhythm:

Daily triage for incidents and major issues
Weekly backlog review for requests and fulfillment
Weekly or biweekly change review for risk and schedule conflicts
Monthly service review for metrics, trends, and control gaps
Monthly CMDB quality review for completeness and freshness

This is what “govern” looks like in practice. Not a policy deck. A cadence.

Automate only the repeatable work

By day 90, automation should focus on known patterns:

Standard request fulfillment
Standard change models
Auto-routing for common incident categories
Notifications and escalations
Basic data synchronization for CMDB records

If the process is still unstable, do not automate the mess. Stabilize first.

Metrics that tell you the implementation is working

A good ServiceNow implementation plan should show operational movement by day 90. Track metrics that reflect execution, not vanity.

Incident metrics

Mean time to resolve
First assignment accuracy
Reassignment rate
Major incident count
SLA compliance

Request metrics

Fulfillment cycle time
Self-service completion rate
Approval turnaround time
Backlog aging
Fulfillment error rate

Change metrics

Change success rate
Emergency change percentage
Change-related incident rate
Lead time for standard changes
Percent of changes linked to a CI/service

CMDB metrics

CI completeness for in-scope services
Relationship accuracy
Duplicate CI rate
Data freshness
Coverage of critical services

If these numbers are not moving, the implementation is not yet delivering business value.

Common mistakes in the first 90 days

Here is the short list of things that usually go wrong:

Trying to implement too many modules at once
Customizing before validating standard workflows
Building a large CMDB with no business use case
Letting every team define its own process
Ignoring data ownership
Starting change management before you have service context
Launching a broad catalog with poor fulfillment design
Measuring activity instead of outcomes

The pattern is always the same: too much ambition, not enough control.

A practical 90-day rule of thumb

If you want the simplest possible answer, use this sequence:

Stabilize incident
Standardize request
Control change
Build a CMDB that supports those decisions
Expand only after the first slice is trusted

That order matters.

Incident gives you volume and urgency.
Request gives you repeatability.
Change gives you governance.
CMDB gives you context.

Together, they create a workflow backbone that can scale.

Final takeaway

The first 90 days of a ServiceNow implementation should not be about breadth. They should be about control. Build a small but credible operating model, anchor it in a trusted CMDB slice, and prove that incident, request, and change can run on one governed platform.

Do that well, and the next phase gets easier: more automation, better analytics, stronger self-service, and eventually AI that acts inside workflows instead of producing expensive advice.