Overview

In his research , Professor Christensen pondered how come so many great companies fail epically so many times, while new competitors apparently emerging out of the blue consistently manage to out-compete the established incumbents despite fewer resources and un-established reputation. Management was certainly not “stupid,”² but Christensen observed flaws in the decision-making process of established market leaders that actively discard the initially modest ideas that smaller competitors instead nurture to great success.

He observed that disruptors like Netflix’s movies-by-mail business for example do not start by competing head-on with incumbent market leaders in Blockbuster-like movie rental shops. Netflix instead first went after an underserved niche: People looking for unpopular films and willing to wait for their delivery over the mail.

The same pattern could be observed in Toyota’s inexpensive Corolla cars, Sony’s Walkman portable stereo, and Uber’s good-enough alternative to car ownership for some people.

Examining real-world case studies such as these Christensen identified that they all followed a similar pattern, dubbed the innovator’s solution. In a nutshell, and in my own words the tried-and-tested solution observed was to:

1. Start with easy-to-please customers at the outskirts of the market;

2. Observe what jobs customers hire the product for and improve it for those specific circumstances;

3. Patiently but profitably capture opportunities to climb upmarket, satisfying more customers from the bottom up;

4. Emerge as an irresistible mainstream offering, while it is too late for established competitors to battle you.

In the first two steps management pursues an emerging strategy, not yet committing to a plan for market dominance.

Only after going live with profitable small customers and setting up a cost structure that is pleased with those low-hanging fruit opportunities a proven strategy emerges to dominate the market.

Emphasizing the importance of pursuing this iterative strategy Christensen notes: “Research suggests that in over 90 percent of all successful new businesses, historically, the strategy that the founders had deliberately decided to pursue was not the strategy that ultimately led to the business’s success.”³ Their ability to identify what works and switch gears is what enabled them to succeed nonetheless.

Intel Corporation for example, started as a manufacturer of memory chips (DRAM) and it took a while for management at Intel to realize that microprocessors instead (at first made for a calculator project) were going to be the future of the business.

The five-step strategy outlined above is, of course, not the only way to win in a market; One could skip all the way to step three and offer mainstream customers arguably superior products. But Christensen’s analysis found that this is precisely what large organizations have almost always done before they failed.

Put simply, you have thin chances of success competing for mainstream customers from the start and a high risk of losing your upfront investments, while those that start from the outskirts with modest plans tend to have more success in the end. Management can have huge visions in both cases, the difference is in the approach only.

In my own research I found remarkable similarity between Christensen’s analysis of failed product launches and failed ITSM initiatives: Smart and competent people on both sides, the same unexpected yet common failed outcome. Furthermore, I could identify Christenen’s solution pattern in the things that worked in our ServiceNow implementation at Al Jazeera and verified the same with other ServiceNow customers and case studies.

Based on this insight, I propose a ServiceNow implementation strategy that could be used as the basis for your patient-but-revolutionary ServiceNow implementation, if you manage to convince management of it and resist big-bang temptations.

Step 1: Pick your customers

The internal customers to whom you first offer ServiceNow matter a lot as they may become active advocates or doom the initiative. By internal customer I mean teams that will use ServiceNow to handle their daily operations work.

As Christensen notes, successful innovators avoid the obvious customer for their product as those will be invested in another system.

Even though ServiceNow may be arguably better the switch can be slow and packed with challenges , and politics. A much better starting point is to find either:

1. Internal customers that are not using a software system yet but have grown in need for one;

2. Internal customers that have abandoned a software system not because it lacks advanced features, but because they needed something simpler and easier to use. (Note how this is different than offering them something that is more functional than their current system.)

Customers like these will eagerly accept ServiceNow for its core functionality and will have a low baseline to compare it with (email and spreadsheets, or a legacy system they didn’t fully use).

The diagram in Figure 2-1 schematically illustrates how to identify your initial ServiceNow users, while the examples below illustrate how this unfolds in the real world.

Figure 2-1. It’s easier to start from customers that desire ServiceNow for its core functionality. Seek them first

Examples

At Al Jazeera, the central IT help desk was not the first internal customer to use ServiceNow. It was the fourth, almost a year after other departments and teams had been using it.

At CERN, winner of ServiceNow’s Innovation Award in 2011,⁴ it was the non-IT general services department that has been cited for triggering the ServiceNow project, while replacing the Remedy system in the IT department did not go live until 2013.⁵

As said in the earlier chapter, the Volkwsagen group, which made a presentation of its ServiceNow Services catalog in 2013, has not yet migrated other ITIL processes from HPSM to ServiceNow.

The more case studies you consider, the more you will find this a recurring pattern with many ServiceNow customers. This helps explain ServiceNow’s expansion outside the traditional IT market and into so-called Enterprise Service Management .

To further illustrate the challenge faced by introducing ServiceNow head-on as a replacement for an existing ticket system that the IT department is used to, consider how the widespread adoption of ServiceNow at Al Jazeera first unfolded.

At Al Jazeera, even though the central IT help desk openly complained about its current ITSM tool replacing their system came with many pre-conditions often dependent on improvements in other tools (e.g. ActiveDirectory), agreements with other teams and business users, and inflated expectations about what ServiceNow should offer from the get-go (e.g. a smart rota system that automatically assigned tickets based on workload and skill). There was a lot of discussion - and a stalemate.

The IT system and network teams , by contrast, had already started using ServiceNow to log and keep track of major changes they planned to make to the IT infrastructure. What made it easy for them to start using ServiceNow’s Change Management tickets right away and without pre-conditions was that they needed to prove that they had planned and obtained approval before making potentially risky infrastructure changes, or ones that involve downtime of business critical services, and they had no system for that. Engineers and team leads found in ServiceNow’s change request tickets an official-enough reference to cover their backs.

Outside IT, a non-IT department in the business was interested in centralizing their communication channels with international bureaus under one system. As told in Chapter 1, it was not easy to launch ServiceNow there either but within a few months a nine-forms Requests catalog for shared services was eventually rolled out (see Figure 2-2).

Figure 2-2. Promotional graphic of nine-form service catalog launched for a non-IT department as first Requests user of ServiceNow

Then again, another group in the IT department got interested in ServiceNow. Senior management in the IT department was looking for a solution to better manage the department’s many contracts and their renewal process ahead of the contracts’ end dates.

Acknowledging the need for some system and not having one, management was interested in using ServiceNow as a searchable repository of the department’s contracts and to trigger scheduled reminders to specific people to remind them of the contract renewal process. So it was that limited-scope Contracts Management in ServiceNow was rolled up, even before Incident Management was.

Then came a new big customer for ServiceNow, from the United States. Al Jazeera had acquired Current TV to launch its new Al Jazeera America (AJAM) channel and integration works were to be completed before the new channel would go live on air. As part of this integration, AJAM management wanted better visibility of all support requests received and still-pending action. A shared inbox was just not enough for them.

There had been a ticketing system but it was seldom used, while most support requests were sent through by email to a team of super-busy technical heroes who were also working on the channel setup. Offering to integrate ServiceNow with email, ServiceNow was again seen as a better alternative to the status quo.

Step 2: Set expectations

In picking your initial customers, I recommended that you go after customers whose expectations can be met with ServiceNow as it is Out-Of-Box (OOB).

In defining the initial scope for the implementation with them you should also make sure that by using ServiceNow they are not outstretching the level of complexity that they are already used to handle in their previous system.

Even if ServiceNow can do it OOB, offering all ITIL processes to a team that just used email conversation for all their issues, problems, and feature requests can be overwhelming. As Gustav Hoyer, former IT director at Sony Pictures puts it: “ServiceNow is incredibly agile. You don’t have to worry about scalability; you just need to make sure the functionality is rolling out at a rate that human beings can absorb.”⁶

As such, you can use this criteria to determine what should be in-scope and out of it for the implementation project:

1. How close is the proposed scope to ServiceNow’s core functionality (OOB)?

2. How close is it in terms of complexity to what the customer is already familiar with and actively using?

The diagram in Figure 2-3 schematically illustrates how to identify the initial scope for a ServiceNow launch, after which an example is given from Al Jazeera America’s implementation of ServiceNow.

Figure 2-3. Define appropriate scope for initial ServiceNow launch

Step 3: Minimal setup

The setup to start managing incidents in ServiceNow at its minimum would only involve configuring users’ access to ServiceNow, but would typically also include configuring email notifications, assignment groups, and a few customizations like setting categories and locations.

To guide implementors through the setup there is in ServiceNow an ITSM Guided Setup that takes them through a 12-step setup (see Figure 2-4) to:

• Map your organization’s structures in ServiceNow: users, groups, locations, departments, companies, etc.;

• Configure connections with your email and authentication servers;

• Define categories, assignment workflows, date formats, mandatory fields, Service-Level Agreements, etc.;

• Set up a Service Portal, design forms, and management dashboards.

Figure 2-4. ITSM guided setup in ServiceNow

For guidance at an architectural level, Part 2 of the book goes over your options for managing users’ access (Chapter 3), routing incoming emails appropriately (Chapter 4), and sending elegant email notifications (Chapter 5). Chapter 6 shows you examples of Service Portals, and Chapter 7 talks about how to make reporting useful for all at all levels.

Step 4: Go live quickly

On its website ServiceNow showcases Pacific Aluminum from Brisbane, Australia for having completed its implementation project within 30 days, but going live within eight days of starting the project.⁷

At Al Jazeera America a few months passed between project start and actual deployment but most of that time was actually spent on other activities, waiting, and supporting existing non-AJAM users on ServiceNow.

Other ServiceNow customers also report taking months in negotiation and preparation for the launch.

As the AJAM channel launch on air approached I was flown to New York to fast-forward the go-live with ServiceNow. Once on-site, it took ten days to go live with a minimal setup.

Most of the time on-site was not even spent on the tool, it was on coordination, training, and hand-holding after go-live. AJAM officially started using ServiceNow before the LDAP integration was complete, as it took a while to set it up between Al Jazeera’s servers and ServiceNow’s.

Step 5: Refine and emerge

After going live with ServiceNow at Al Jazeera America, I stayed there to assist the teams using ServiceNow, observe what was not practical or caused confusion, and fine-tuned ServiceNow to fit the job better.

It is important to note that at AJAM there was a daily stream of new people joining and that had to use ServiceNow, so we could not rely on expecting them to remember how to do the right thing. We had to make doing the right thing the default thing to do.

Throughout the book and in Chapter 11 you will find details of changes made to ServiceNow in the pursuit of eliminating room for error and encouraging the desired behavior, as ServiceNow usage grew globally.

How do you know if people are actually using ServiceNow effectively? Reports in ServiceNow (Chapter 7) can measure different aspects of ServiceNow usage to determine what is not being used effectively, or who it is who is not using it. From there you can decide to simplify procedures, change defaults, or approach the people in question.

After the successful launch of ServiceNow at AJAM, there was more appetite for using ServiceNow by the core teams in Doha, and many of the earlier hurdles disappeared. Something like ServiceNow at AJAM was now considered sufficient, and in fact desirable.

The more teams signed up to use ServiceNow, the more people interacting with those teams received neat email notifications sent from ServiceNow about their ticket’s status (see Chapter 5). The word spread quickly and more teams and managers asked to use ServiceNow in their team.

Then HR teams also got interested in using it to track their requests and collaborate on issues with ERP teams.

In the end, ServiceNow had emerged as a mainstream corporate application used daily, while the discourse changed from “What are all the things ServiceNow should be able to do before it can be beneficial to us” to “Why are not we on ServiceNow also?!”

This is what I also hope for your implementation. It takes patience and comes with uncertainty as to how exactly things will unfold, but if it works it will be worth it.

As you on-board more teams, new issues show up that can jeopardize current users or hinder new ones (e.g., confidentiality). Part 3 of this book proposes solutions to common issues faced at this stage.

Tweet-ready takeaways

• It’s easier to start with customers who desire ServiceNow for its core functionality . Seek them first.

• Those starting modestly from the outskirt tend to succeed in the end. They too can have huge visions, the difference is in the approach only.

• Change the discourse from “What are all the things ServiceNow should do before it can be beneficial to us” to “Why are not we on it also?!”

• Big things have small beginnings. Going live quickly is not a feature of maturity, it is a reflection of how small the scope is.

• When real people use your product in real-world situations, you can observe how they use it and not use it and make it better for real.

• Push out quickly, follow up, make corrections, push again, make corrections, push again, and so forth.