Bringing in an external partner to implement an out-of-the-box solution: a contradiction or not?

One of the things in life that give great satisfaction are those unforeseen, unplanned encounters with people from a previous phase in your life. Recently, I literally ran into one of my former fellow-students at the VUB. We crossed paths when running on one of my favorite running tracks in the neighborhood. More than 15 year since our last encounter…  

“So, you ended up in IT and are busy with ServiceNow, that ticketing tool, right?”  

I could not just let it pass like that and started explaining the platform vision to him. Now that’s not the purpose of this blogpost (more info on ServiceNow itself can be found here), but I was more intrigued by what followed next in the discussion and which led to this post. He understood from my explanation that ServiceNow is a 100% cloud solution. We don’t have anything to install, we don’t host the solution, we don’t need to look after the backups …  

“So, no services to be provided by you for that part”. Well… no.  

And you want to stick to the ‘out-of-the-box’ solution, provided by ServiceNow, built on ITIL best practices.  

“So, no services to be provided for that part either”. Well…  

We didn’t go into detail and had to end our conversation there, but the question kept popping into my head, and I decided to write this post. What are the services provided with an out-of-the-box ServiceNow implementation? 

1. Who? When? What? Why?  

The customer has decided to start with ServiceNow. Perfect. This decision can come from different people, departments, units, … It doesn’t matter for now. What does matter is that you define who needs to be involved in making this project a success. Involved means taking part in the actual work or just being aware of the progress. Communication is crucial and roles need to be defined. Who is the project sponsor, who is the technical architect? Is the security team involved? Is the project part of a global program? 

Stakeholders should be aware of the project and its progress. Agendas for upcoming workshops need to be booked. A lot of projects fail by not involving or informing the right people, resulting in a lack of buy-in. A successful implementation is the result of a fruitful collaboration between customer and partner. This requires time from the customer. A lot of time. Do not underestimate this. We call this phase the initiation phase of the project. The result is that the project team is ready to start the workshops and people are informed of what is expected from them and how this contributes to the common goal of the organization.  

2. “We don’t work like that. Our organization works differently. “ 

As mentioned before, we aim to stick to an out-of-the-box implementation of ServiceNow. Staying aligned with the ‘out of the box’ will guarantee smoother future upgrades. Too many times, we meet with customers who are afraid of upgrading due to too many customizations. But first, the customer needs to understand what exists in ‘out of the box’, how incidents are handled, how changes are performed …. One might wonder if this was not clear from demonstrations in the sales/decision process. The answer is – only partially. In the sales process, the focus is more on the outcomes, on the end-user experience, on the dashboards, on the reporting, on how all the processes are linked on the platform, on the platform capabilities itself etc.  

We hold workshops per process. Processes are Incident, Request, Catalog, Change, Problem. We align with the ITIL processes – this will not be a surprise. The goal of the workshops is to explain and show what ‘out of the box’ comprises and going into the details. Let’s take the example of how an incident is handled. The incident goes through different states.  

When selecting ‘on hold’, an on-hold reason should be provided. Options are awaiting caller, awaiting change, awaiting problem, awaiting vendor.  

Customers might state that they don’t use the ‘on hold’ state and don’t need it. This is an example of a process discussion and we aim to convince the customer to use it so they can better track SLA and be able to act where needed, or to understand why they do not need it… 

When it comes to Request Management, we define together with the customer what information we need from the requestor to proceed with the request. A very important guideline related to this is the following: avoid asking the requestor for information you are supposed to already know. Imagine a request for adding additional memory in ‘my laptop’. Best practice is to avoid having to ask the user for the serial number or the tag of that laptop. The same goes for questions such as: who is your manager? Which department are you working in? Too often, we still see companies asking their users these kinds of questions.  

When, during the workshops, we run into the famous “we don’t work like that” comment, we explain that for 95% of the companies around the globe the ITIL framework provides a good base to start from. So, there must be a good reason why it wouldn’t work for you. On the other hand, we also aim to stay pragmatic and not be obsessed by ITIL. It provides an excellent framework and a direction of where to go, trying to avoid a big bang approach. This is also one of the principles introduced in ITIL 4: “start where you are, progress iteratively”.   

The result of this phase, which we call the agreement phase, is that the implementation team is ready to start configuring the ServiceNow instance of the customer.  

3. Configuration versus customization 

In this phase we start implementing. The previous agreement phase resulted in user stories to be worked on by the implementation team. It will come as no surprise that we use ServiceNow as the technology to keep track of the stories, organized by epics and themes. It’s interesting to know that ServiceNow offers a free Devops starter module. For a simple tracking of work, this is an excellent tool. See below an example of how we at ASP used the Devops starter module to keep track of our work while creating our Challenge Application on the NOW platform.  

During the implementation we stick to the principle of avoiding customization, being defined as “developing custom code to change the out-of-the-box functionalities of the platform”. Sometimes the line between configuration and customization can be perceived as a very fine one. The following are a few guidelines:  

• Is the proposed solution supported by ServiceNow? If yes: Configuration 
• Can this be solved using existing functionality? If yes: Configuration 
• Is this documented in Docs? If yes: Configuration 
• Is this extending existing functionality?  If yes: Configuration 
• Will this affect future upgrades? If yes: Customization 
• Does this fundamentally change the behavior of the platform? If yes: Customization 
• What skills are required to support this? (advanced skills MAY imply Customization) 
• What is the level of effort? (higher levels MAY imply Customization) 

Some concrete examples of configuration work are as follows:  

• Form Layouts: e.g. the Incident form is used to log incidents in your instance. We reviewed the default Incident form. We can configure the form layout by adding, rearranging, or removing fields. 
• Categorization: categories and subcategories are used to ensure an incident is routed to the team that is best equipped to restore normal operations. We analyzed in the previous phase the most-used categories to gain insight into the type of issues impacting your business. We can configure the default categories for any specific business needs. 
• Assignment Rules: Assignment rules help reduce resolution times and ensure that incidents are routed correctly. The rules automatically assign an incident to the correct resolution team. We configure assignment rules to route incidents to specific teams according to information in the incident records, such as the category, subcategory, or configuration item (CI). 
• Dashboard Creation: visual representation of critical incidents, unassigned incidents, overdue incidents etc. 
• Configuration of the Change Blackout Schedules: Use blackout schedules to specify time periods when changes for a configuration item cannot be implemented. The instance does not come with any predefined blackout schedules. 

Throughout the implementation, our consultants perform unit testing: verification of the completed story respects the defined acceptance criteria.  

Ending this configuration phase results in the organization being ready to start user acceptance testing.  

4. “What was the URL again of our support portal…”  

The fourth phase of our project consists of different activities starting from the user acceptance test and resulting defect remediations, to training and finally the actual go-live. An absolutely crucial part in this phase is the communication towards your customers, the people who will use the solution. As mentioned earlier in my blog post, communication towards project stakeholders and sponsors is important at the kickoff of the project and remains as important throughout the implementation. But in this phase, communication needs to go one step further. You can have the best solution, but if no one knows about it, it is a pure waste of time and money. A concrete example we ran into was at the beginning of a training for people responsible for IT changes in their organization. We worked hard, together with key users to implement the solution; we were proud of our work. We started the training full of excitement, dived right into slide one of our well-prepared slide deck and when the first questions were asked…. we were taken by surprise.  

“Does this mean we stop using our old tool?”  

“What is that ServiceNow thing”?  

“Why are we replacing our tools?”  

The people in the classroom had no clue why they were there and what the bigger picture was. In all our excitement, we forgot the most basic thing: explaining why we change, what it will bring to the organization and to every single individual and what the purpose is of the training. We thought the customer would do it, the customer thought we would do it and, in the end, no one did it. Lesson learned, clearly. Do not underestimate this communication, part of the entire organizational change management. It can make or break your project.  

The same is true for your end-user community. You can have the fanciest portal on the planet, but if it is hidden somewhere on a forgotten intranet, it will simply be a hidden gem forever. Communicate to and with your user base.  

In this phase we transition from configuration to go-live. Well, actually we go one step further. The days right after go-live, we foresee an extended presence of our team to assist our customer in providing this post go-live support. “I am not able to login”, “Where is that report again?” are typical issues we get during the first days after the roll-out.  

5. “Can(’t) we do this ourselves?” 

A few weeks after the go-live, it is time to take one step back and evaluate the work of the previous months. What went well? What should we do differently in a next release? A key element in the successful usage and further rollout of the ServiceNow platform is the knowledge available internally at the customer. This might sound like a contradiction, resulting in less services for us, as implementation partner, but is the exact opposite. We cannot stress enough the importance of customers having a dedicated ServiceNow platform owner whose role it is to understand what ServiceNow can offer, what the roadmap is and how to make the bridge to internal projects and initiatives. And then discuss with the partner what the best way would be to implement it. It really is a win-win situation. Customers who appoint a dedicated platform owner, get the most out of their investment. Knowledge sharing from our implementation team to the customer team is part of the project.  

Yes, customers can also do implementation work in the platform themselves. Combined with the experience from other implementations of a partner, the success rate will be higher. 

Let’s go back to the beginning of the blog and my friend from the early days. I will send him the link to the blogpost and can’t wait to discuss it further while having a (few) beer(s). I hope he understands better what the services are that we deliver, even when the customer sticks to the out-of-the-box solution from ServiceNow.