When setting out on an implementation, your chances of realizing value will be much higher if you actively manage specific value outcomes. This section will provide an overview of value and its management in the context of a ServiceNow implementation so that you can clearly define the value expected in your own implementation.

What is value?

To achieve value, it is first necessary to understand what it is. Simply put, value is the benefit that your organization receives from some activity or investment. The value of a financial investment includes the price you receive when you sell it and the value of a piece of fine art includes the pleasure of owning and displaying it. Similarly, the value of ServiceNow includes all the benefits that result from its implementation. Value can be financial or non-financial, and it can accrue to yourself, your customers, or your shareholders. It is also sometimes referred to as the return on investment (ROI), benefits, or positive outcomes – in all cases, value is the desirable result of an investment of resources in the execution of some activity.

Why is managing ServiceNow’s value important?

This book is predicated on the assumption that the leaders who sponsor and commission implementation projects such as a ServiceNow deployment are doing it because they wish to reap measurable benefits from the outcomes of that implementation. While some small minority of projects may be commissioned for other reasons (that is, political maneuvering), it’s much more likely that someone is investing and hoping to see tangible benefits.

The value of ServiceNow must be clearly understood at the outset of a project to ensure it will be realized. If the planned benefits are not realized, then the implementation will have failed even if there is a go-live where cake is served (it is a tradition in the ServiceNow community that each major go-live is celebrated with a branded cake). While some would hope that simply introducing ServiceNow immediately provides you with a vast array of benefits, it is the careful and considered application of that tool to your company’s business processes that will help you achieve the objectives. Actively managing the value of your implementation will result in a higher ROI, which, depending on your role, will translate to a more satisfied boss, customer, or stakeholder group.

Who is responsible for value?

The leader commissioning and sponsoring the ServiceNow project will ultimately be responsible for the ROI – for this reason, the final responsibility lies with the project sponsor. However, in many cases, this responsibility is delegated to a project leader who will chair the steering committee and serve as the person charged with the success of the project.

This project leader may delegate the responsibility for daily management of project work and outcomes further to a project manager. However, at the end of the day, a team will be charged to deliver the project’s outcomes and the daily work of implementing ServiceNow will fall on their shoulders. What is essential, regardless of the number of levels in your project’s governance structure, is that clear and continuous communication around value occurs from those doing the work to those responsible for the outcomes. The facilitation of this communication is the responsibility of the project leadership team and the project leader.

Alongside the primary responsibility of the project leader, there is the opportunity for every member of the team to take ownership of their contribution to the project’s value. This ownership includes identifying value opportunities, documenting value statements, aligning the project execution with the desired outcomes, and drawing attention to any risks to value realization. In this sense, if you are reading this book, it is likely that you are responsible for value in your role in ServiceNow implementation and that by focusing on bringing success to your implementation rather than the often-stated goal of going live, you can make an outsized impact on the benefits that will be achieved.

How do we define value?

Defining value is difficult and many projects get launched and even completed without this essential step – however, if the value is not defined, there is little chance of it being realized. A useful practice for defining value is the creation of value statements that can precisely anchor the discussion of value:

• You should always describe the mechanism for value generation in your value statement so that it can be used to steer decision-making on your project.
• You should always define a value statement regarding some group or organization – even a brick of gold is only valuable if someone can make use of it and gold ore deep below ground is only potentially valuable.
• You should always strive to quantify value in a value statement, even if it’s a non-financial metric – otherwise, you may not be able to determine whether a particular element of value was realized. At the end of the day, if you can’t tell whether the value was achieved, then it probably wasn’t.

Here’s an example of a value statement - Automate widget request sourcing: The introduction of automation into the widget request process at the sourcing step reduces effort on the part of the widget manager by 15 minutes per request, with a cumulative annual savings of 460 hours, while reducing the time customers wait for their widgets by 1 day.

In almost all cases, value statements should be documented in a location that is accessible to your project teams, except for value statements relating to confidential activities such as unannounced organizational change or a material event such as an acquisition. By making the value statements available to your project team and referencing them throughout your project, you increase the probability of these benefits being realized. In projects being delivered by your own organization, your project charter or project business case may incorporate the value statements. In the case that a consulting or professional services organization is working on your implementation, the documentation on the project scope of the work can serve as a useful place to define these outcomes and to ensure alignment between all parties.

Types of value

While the value proposition of each project in each organization may be slightly different, years of implementing ServiceNow across diverse industries have shown that some common themes re-occur. Each of these provides a significant opportunity that should be explored in the context of your implementations, but it is most common for organizations to choose one or two as a primary focus of their projects. The four general themes are the following:

• Service quality
• Cost optimization
• Customer experience
• Innovation enablement

Each theme deserves independent treatment and the remainder of this chapter will be dedicated to describing these areas of value and the specific considerations that should be applied to the ones you target. In particular, we will review the important information needed to effectively drive value for each area to support you in determining which value opportunities you will target and what activities, features, or modules you will include in your scope to achieve those opportunities.

Perhaps the most classic ServiceNow use case, the theme of service quality relates to an organization’s ability to deliver what they have committed to. The nature of services may vary but the underlying principles are quite similar and even the terminology used to manage them is often aligned. In an IT organization, service quality is the availability and smooth operation of the enterprise software and hardware, from laptops to Wi-Fi and from email to accounting systems. In a telecommunications company, service quality is about the stability and speed of communications services such as the internet and cable TV, while for an internet company, the availability of their website might be the primary consideration.

Defining a service scope

When striving toward service quality improvements, it is critical to define a service scope consisting of the services whose stability we aim to improve or maintain. This is easiest in an IT organization where the service scope might be “all systems managed by IT” or more commonly, “All production systems managed by IT,” but again, the same principles can be applied to other domains.

ServiceNow supports service quality primarily within the IT Service Management (ITSM), IT Operations Management (ITOM), and Customer Service Management (CSM) product areas, although other products are involved for particular use cases as well. The starting point for most organizations focused on service quality improvement is usually the establishment of ITSM processes for in-scope services. In these cases, it’s common to see scopes targeting all data center devices, or everything on the network – the underlying assumption being that if all the individual components are running smoothly, then the collective service is also performing as expected.

In defining a service scope, you may include components such as servers, switches, or storage arrays, and you will also need the list of business or application services that you are targeting. With ServiceNow implementation in particular, it is essential to at least define the applications that these components support, as these form one of the cornerstones of the ServiceNow Common Services Data Model (CSDM) as Application Services (more detail on the CSDM can be found in the current version of the ServiceNow published "CSDM Whitepaper" available from ServiceNow).

Some guidance on service scope is warranted, as companies often try to tackle all systems and services for service quality optimization simultaneously – while that is possible, it also requires an expert level of coordination and is subject to significant risk. A more targeted approach can remove risk and decouple these objectives, allowing you to move rapidly in a small domain to deliver value quickly. It also allows an implementation team to build confidence by tackling a smaller problem with a clear end in sight, rather than a single goal that is difficult to envision reaching and even more difficult to execute.

Service quality metrics

It is common for projects to be commissioned with high-level value objectives tied to a value theme such as service quality. Organizations may know that there is work to be done to keep things running smoothly but have not yet translated that into actionable metrics. In these cases, the project team will now need to collaborate with stakeholders such as business and IT leaders and service owners to create clear value statements for service quality tied to specific service quality metrics. Some examples of value metrics related to service quality include the following:

• The number and severity of SLA or SLA breaches
• The number of critical incidents
• Unplanned downtime of mission-critical systems
• Failed customer interactions with your mobile application

Note that while these are quantitative metrics that undeniably matter to your organization, they may or may not be financial metrics. An SLA with your customer may incur penalties for being violated but an internal OLA isn’t likely to have a hard dollar cost associated. This will be a common trend in your ServiceNow journey and will be repeated for other value-related themes. Recall that a value statement should be measurable in terms of the impact on a specific group of individuals. This requirement should be easy to meet when formulating service quality metrics and value statements, as you generally know what the user demographic of a service is. Examples of user communities can include employees in the accounting department, your customers, or your suppliers.

A value statement for service quality might read as follows - Reduce the impact of database anomalies during the month-end close: Monitoring and responding to anomalous database performance during peak periods around the month-end close reduces overtime worked by the financial accounting team by 50%.

This value statement is clear in scope and delivers value to a clear audience, although whether the accountants are working long hours or the budget holder is footing the bill for the overtime pay may depend on the organization. By targeting specific systems or services that have a measurable impact on the organization, you avoid a peanut butter approach where a diluted version of the value is spread across a large surface area of applications. This is important because a very small impact on a large number of teams can be difficult to measure and it therefore becomes difficult to show that an improvement is related to the efforts of your project team.

Planning for service quality

With the metrics established, the next task for your team will be to develop and execute a sequence of activities that lead to the realization of value. A critical step will be to confirm that you have the appropriate ServiceNow licensing in place to support the service quality value objectives and that your project work plan includes the activities required to deliver on those value objectives.

If there are any gaps, you must work with your project management and governance structure to either modify the plan or the objectives. This is an essential point, as all too often, the connection between objectives and the plan is ignored. If you as an insider within the project, a dedicated member of the team, or a seasoned leader overseeing the project can’t tell how a particular objective will be achieved, then there is a good chance that it will not be.

Identifying opportunities in the current state

If service quality is a target outcome for your project, then you should understand the current state of the in-scope services first. This is a common challenge where organizations believe that the current state is not relevant to their future state. They are re-imagining their IT operations and implementing an entirely new ServiceNow instance after all. Experience shows that a good map is substantially more valuable if you know where you are starting and for that reason, it is worth your while to get a sense of how the processes are currently performing.

Questions to ask include the following:

• How stable are the services?
• When something goes wrong, how quickly is the issue detected?
• When investigated, what are the common root causes?
• How often are issues resolved at the service desk versus being resolved only after escalation?

Answering these questions will help you map specific ServiceNow capabilities to the problems most relevant to these services. This, in turn, allows you to focus your resources on the key levers to drive improvements in your objectives.

Aligning the implementation scope with the opportunity

If you find that the in-scope services often fail due to changes being made to those services, then that suggests it’s necessary to focus on the change management process to better assess and manage risk. ServiceNow has specific capabilities in ITSM for change risk calculation to help you navigate that scenario. However, if an unreliable software solution, perhaps one prone to memory leaks, is spontaneously failing after some time in stable operation, then the instrumentation of that infrastructure and application using the ITOM monitoring capabilities should be considered to identify leading indicators and even execute automated remediation steps as a stopgap until the software is updated.

The essential process of discovering the problems or opportunities that exist in the service quality requires you to speak to those who are knowledgeable about the services, analyze the data, and think critically about how the capabilities you will implement can bring about a positive change for their teams. During this time, keep an eye out for teams who have substantially better service performance or who have established and proven solutions for managing their systems.

If you are operating from a templated plan or even one devised at the outset of the project when you had very little information, now is a good time to revisit your planned activities and to critically assess whether changes are required to remain on track to deliver value.