01 / SCOPE
Outcomes and ownership
Name users, owners, approvers, delivery teams and accountable outcome.
A platform health and readiness assessment suits the person who has to make a decision about a ServiceNow platform and cannot yet see what that decision rests on. That person is rarely the developer. More often it is the owner of the service management toolset, a program lead asked to approve a release, or an IT leader who inherited a platform whose history was never written down. Four kinds of reader tend to get the most from the work:
The review is less useful to someone who wants a single score or a list of every possible improvement. Its output is meant to support one decision at a time, so the reader should be able to name that decision before the work begins.
Triggers tend to be concrete. A release has been postponed without a clear reason. Approvals take far longer than the documented process suggests. A new team has inherited customizations nobody can trace. Two reports disagree about the same service. Each trigger points at a different part of the platform, which is why the first conversation should establish which symptom prompted the request.
| Trigger | What it often indicates | What the assessment should establish |
|---|---|---|
| Repeated release slippage | Unclear scope, unresolved dependencies or testing that begins too late | Which dependencies block the next release and who owns each one |
| Slow approvals | Routing rules that no longer match the real delegation of authority | Where approvals stall, and whether the rule or the people are the constraint |
| Inherited customization | Changes made without a register or without a named owner | Which customizations carry the most risk and which could be retired safely |
| Conflicting reports | Different data definitions, or source records nobody reconciles | Which definition is authoritative and which records feed each report |
| Growing support volume | Catalog, knowledge or routing design that does not match how users ask for help | Which request types create avoidable work and where they are routed |
Where the trigger is a data problem rather than a configuration problem, the review should point to the CMDB, CSDM and ITAM page, which covers configuration data, because the remediation then depends on ownership decisions that sit outside the platform build.
A written boundary protects the credibility of the findings. Exclusions usually include custom code outside the named instance, third-party systems that only send data in, performance tuning beyond what the stated questions require, and any module the buyer has not licensed or deployed. Each exclusion should appear in the scope record with a reason, so that a gap noticed later is understood as a deliberate limit rather than an oversight.
Delays at the start of an engagement often come from access rather than analysis. The customer should expect to provide the following before the first working session:
Where security policy restricts access, a review can often still proceed on exports and structured interviews. The findings should then say which conclusions rest on direct evidence and which rest on what people reported.
| Role | Responsibility during the assessment | Typical output |
|---|---|---|
| Business owner | Confirms the decision, the scope and the priorities, and resolves trade-offs | Signed scope record |
| Platform administrator | Provides access, explains historical choices and validates findings | Corrected configuration notes |
| Integration owner | Confirms data flows and failure routes | Integration map annotated with owners |
| Assessment lead | Runs the stages, keeps the evidence and writes the findings | Findings register and readout |
| Operational lead | Confirms how work actually moves through queues and escalations | Confirmed routing and escalation notes |
Responsibilities should be named before the first stage begins. An unnamed owner is a finding in its own right, and it is often the most important one in the register.
Work of this kind is commonly framed as five stages, each with a clear exit condition, so a sponsor can see when evidence is sufficient to move on.
The length of each stage depends on the size of the platform and on how quickly access is granted. Timing and staffing follow from those two factors and cannot be fixed in advance.
A long list of observations does little for a decision. Findings are usually ranked by asking four questions, in this order:
A finding that is severe but expensive to fix may still sit below a cheaper change that removes a recurring failure. The readout should show this reasoning, not only the final ranking.
The table below shows the structure a register of this kind commonly takes. Its entries are illustrative examples of the format. They are not a client result and do not come from any engagement.
| Field | What it holds | Illustrative entry |
|---|---|---|
| Finding reference | A stable identifier used in the readout and in later tracking | A prefix followed by a sequence number |
| Area | Configuration, data, integration, role or operating routine | Assignment logic |
| Observation | What was seen, and where the evidence is held | An assignment rule refers to a group with no active members |
| Effect on the decision | How the observation changes the next release or support route | Tickets can stall without a visible owner |
| Priority | The result of the four questions above | High, medium or low, with the reason stated |
| Owner | The person accountable for the fix | A role name rather than an individual |
| Dependency | Other findings or decisions that must come first | Reference to another finding |
| Status and verification | Open, agreed or closed, with the method used to confirm the change | Export compared before and after the change |
Keeping the register in this shape allows the customer’s own team to pick it up without the assessment lead in the room.
A fixed price is hard to state in advance, because the same headline scope can produce very different effort. The main drivers are these:
Scope, staffing, duration and price all follow from these drivers. Any proposal should tie its effort back to these drivers so the buyer can see what would change it.
As a rule, no. A review reads configuration, data samples and documents. Any change is a separate decision, made after the findings are agreed, and it follows the customer’s own change control.
It can, with a narrower evidence base. Exports, screen walkthroughs and structured interviews can support most findings, but the register should mark any conclusion that could not be checked directly.
An implementation builds or changes the platform toward an agreed design. An assessment establishes what the platform is doing now and what should happen first. Many buyers use the second to shape the scope of the first. The ServiceNow implementation page describes the implementation route.
The readout should say so plainly. A rebuild recommendation is one possible outcome. It carries its own dependencies, sequencing and cost drivers, so it is treated as a separate decision rather than a hidden extension of the review.
A useful first conversation covers the decision, the people involved and the access that exists today. Bring the release or question that prompted the request, along with any documents already in circulation. If the reader is still choosing between a review and an ongoing support arrangement, the support and maintenance page and the managed IT services page describe those ongoing routes. The next step is to Discuss your platform assessment and describe the decision the platform has to support.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.