ServiceNow Change Management Consulting

What a Change Management Consulting Engagement Covers

A Change Management consulting engagement with Oblytech typically begins with an assessment of your current change process, if one exists, or starting from scratch if change is currently informal. We document what is changing, how often, and the impact of changes: do deployments cause incidents? Do changes exceed their planned duration? How many times do changes need to be rolled back? We interview leaders and change managers to understand risk tolerance, approval authority and desired governance level.

We design a change management framework that balances speed and safety. Not all changes require the same approval level: a routine patch is lower risk than database schema changes. We design a risk assessment approach so changes can be categorised quickly. We build approval workflows that move fast for low-risk work and bring appropriate oversight to high-risk changes. We establish governance: who decides which changes are approved, what the criteria are and how decisions are made. Implementation length depends on complexity and change volume.

Typical Starting Problems and Governance Challenges

Organisations often react to change-related failures with stricter processes: everything requires approval, every change needs documentation, every change needs testing. This over-governance slows down delivery. Teams work around the process by doing emergency changes that bypass approval or by bundling many small changes into one big change to reduce approval overhead. The process becomes a bottleneck that teams resent rather than a safety mechanism they value.

The opposite problem is no governance: changes are deployed ad-hoc, sometimes causing incidents, but there is no systematic way to prevent recurrence. Teams do not know who has deployed what, so they search the changelog looking for the cause when incidents occur. Knowledge of why changes were made is lost when the person who deployed them leaves. Striking the right balance is the key: enough process that risk is assessed, but not so much that work is delayed.

Change Categorisation and Risk Assessment

We develop a change risk matrix that maps change characteristics to risk level. Standard changes are routine, low-risk and reusable: patching an app server, adding a known user, deploying a routine report. These have pre-approval and do not require review each time. Normal changes are assessed individually: they might affect production but risk is understood and mitigation is planned. Emergency changes must fix urgent production issues and bypass normal approval but are documented for post-incident review.

Risk factors include scope (how many systems affected), timing (during business hours or a window when impact is tolerated), rollback complexity (can we undo this quickly) and business impact (how many users are affected if it fails). An experienced team can assess these quickly and assign appropriate approval level. We create decision tools that guide teams through the assessment so categorisation is consistent.

Approval Chains and Authority Framework

We design approval structures that respect decision authority. Low-risk standard changes might need only team lead approval. Normal changes affecting customer services need approvals from affected teams and possibly business stakeholders. Changes affecting security or compliance need security approval. High-risk changes might need director-level approval or a formal Change Advisory Board review. We document who has authority to approve what and why, so when questions arise it is clear who decides.

Parallel approval accelerates decision-making: approvers from different teams can review simultaneously rather than sequentially. Approval hierarchies with escalation paths help: if the first-choice approver is unavailable, the change escalates to their manager. This prevents changes from stalling while someone is in a meeting or on leave.

Implementation Workflow: Planning, Approval, Execution and Verification

The change workflow guides teams through structured steps. Planning: create a change record with title, description, risk assessment, affected systems and rollback plan. Communication planning: who gets notified and when. Approval: route to appropriate approvers based on risk. Scheduling: coordinate with business teams and pick a window that minimises impact. Execution: teams deploy changes and communicate progress. Verification: confirm the change achieved its goal and did not cause unintended side effects. Closure: document learnings and mark the change complete.

Automation can accelerate the workflow. Low-risk changes can skip some steps. High-risk changes might have additional gates like mandatory testing or independent verification. Workflow should be configurable so it evolves as your team’s maturity and risk profile evolve.

Communication and Stakeholder Notification

Clear communication is essential so stakeholders know changes are coming and understand impact. Notifications should be specific: which systems or services are affected, what users will experience, planned duration and rollback plan if needed. Send notifications well in advance for planned changes. For emergency changes, notify as soon as possible about what happened and when it will be resolved.

After changes, communicate outcomes: did it succeed, were there issues and what is the status. Brief post-incident reviews on failed changes help teams learn without blame. Documentation of what was changed and why supports future troubleshooting and knowledge.

Choosing how much governance each type of change needs

This section is for the head of IT operations who has been asked to choose a governance level for change, and who is caught between two complaints: that changes are too slow to approve, and that changes break things without anyone having looked at them. A consultant can help, but the decision that matters is a policy one. How much review each kind of change receives is a business choice about risk, and it should be made explicitly rather than inherited from whichever incident was worst last quarter.

The useful starting point is to separate the decisions that need a group from the ones a single accountable person can make. Group decisions usually concern the classes of change that affect many services at once, or that touch security and compliance commitments. Individual decisions cover routine work whose outcome is well understood. A consulting engagement should leave the organization with an explicit rule for each class, a named person for each decision, and a record of the reasoning, so that future changes can be routed without reopening the policy each time.

Matching review depth to change type

The table is deliberately short, because the consulting value lies in making each row concrete for the organization’s own services. The point to test with stakeholders is whether an approver can say what they are approving in one sentence. If they cannot, the row is set too broadly. The change risk assessment discussion covers the factors that usually belong in that sentence.

Preparing the decisions before the workshop

1. Pull the last six months of change records and group them by type, outcome and the service they affected, so the workshop starts from what actually happens.
2. List the services where a failed change would be visible to customers or regulators, and mark them for the highest review level.
3. Name the person who can decide when a change may proceed during a freeze, and what evidence that person requires.
4. Agree what counts as a standard change in your environment, since definitions differ widely between organizations.
5. Set the rule for emergency changes and the deadline for retrospective review, so the exception route cannot quietly become the normal one.
6. Decide who keeps the policy current, and how changes to the policy are recorded and communicated.

Where change governance designs stop working

The most common failure is a design that copies a published model without adjusting it to the organization’s risk profile. A process that suits a regulated platform team can make a small product group unable to ship. The reverse also occurs: a light design that works for a stable estate collapses when a new service with many dependencies is added, and nobody notices until an outage. A second failure is a change board that reviews everything because nobody wants to own the decision. Attendance grows, the meeting lengthens, and the review becomes a formality.

A third failure is measuring the process only by how many changes pass through it. A better signal is whether changes that were approved produced the outcome that was expected, and whether emergency changes are becoming more frequent. The change models for standard, normal and emergency work cover how those categories interact, and the change advisory board decision guidance covers how to keep the review proportionate.

Questions to resolve with a consultant

Do all changes need a change record?

Changes that alter production services should have a record, and routine work can use a template that carries the record’s content automatically. Keeping a record for everything, including trivial work, teaches teams to see the process as paperwork. The aim is a complete record for anything that could affect a service.

How do we decide who sits on the change board?

Include the people who can make a decision about the services in scope, plus one person who represents operations. Anyone who only wants to be informed should receive the outcomes, not a seat at the table.

What should happen if approvers are unavailable?

Define a named delegate for each approver, and an escalation path that ends with a single accountable manager. Without this, a change can wait for days because one person is on leave, and teams start bypassing the process to avoid the wait.

How often should the governance design be reviewed?

When the service portfolio changes materially, and at a regular interval agreed with the change owner. Review should include the change outcome data, not only the design document.

Next step for designing change governance

Start the governance decision with your own records rather than with a template.