The Dreaded C-Word

[Chris Pearson]

Disclaimer: The ideas, thoughts, and opinions in this post reflect my own views and do not necessarily represent the views of my employer, Accenture.

You all know what word I’m talking about…custom.

There’s so many questions and concerns that relate to this one little word during a ServiceNow project. We’ll get into many of them on this blog, but for today I’m going to focus on definitions. Without setting a baseline for what we mean when we say ‘custom’ or ‘configure’ we will inevitably all end up another c-word…confused. Unfortunately, most ServiceNow projects overlook setting these baseline definitions at the start of the project and inevitably find that teams are all working under different assumptions of what’s allowed versus what’s not.

Before I come out and give you my definition of a customization in ServiceNow, we need to understand WHY we care about customization on the platform. Knowing this actually helps to define the term. With ServiceNow’s existing support model, customers will be required to upgrade their instances a minimum of once per year in order to stay current enough to receive support from ServiceNow. Because of this, we want to keep customization on the platform to a minimum so that your ‘major release upgrade' projects can be measured in weeks and not months. Remember, while your development resources are working on the upgrade of your platform, they are not working on enhancements, defects, or the next module you want to deploy for your company. The fewer customizations we have to test to ensure they continue working on the new code level, the quicker the upgrade project will be completed.

Keeping this in mind, I define a customization to be any change to existing code that comes baseline with ServiceNow or any net-new code you have added to the platform. Notice I used the word code. I’m primarily referring to server side code…business rules, script includes, UI Actions, and the like. I’m not concerned about UI Policies or Client Scripts as much with this definition, and I’m certainly not talking about new fields added to existing tables.

But wait…what about…? There are many areas of ServiceNow that everyone will have different opinions about whether that thing is a customization or a configuration. The bottom line for me points us back to our ‘Why?’ question above. Is changing this object or adding this new object going to lengthen our upgrade projects? If so, it’s something to care about and therefore should fall into our customization bucket. If not, it falls into our configuration bucket.

Should all things defined as a configuration be green-lighted on a project then?

No. Please, no. The most common feeling consultants have at the end of projects is a sense their customers just committed ‘death by over-configuration.’

This is where the confusion often starts on projects. "If adding a field to a form is not considered custom, is quick and simple to do, and doesn’t elongate future upgrade projects, why can’t I have everything I want?" It is these customers who often fall into the biggest trap out there. That is finding that at the end of their ServiceNow project, they have simply rebuilt the exact same system they are about to migrate off of. This situation is often referred to as customization. I’ll hear, "Man, Company ABC customized the crap out of their instance!," That’s not entirely accurate. They over-configured the crap out of their instance...which often times is just as bad.

In future posts, I’ll discuss ways to avoid these different pitfalls.