So, You Want a Customization?

[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.

Now that we know the difference between a customization and a configuration (See my previous posts), how do we decide what’s allowed and what’s not?

The name of the game is governance. Doing this whole ServiceNow thing correctly requires good governance. While overall governance of ServiceNow is a larger discussion, the below list of concepts is focused primarily on properly handling customization requests. Putting a process around these concepts will lead you down the path you're looking for.

1. A platform owner must be defined. This is a single person who has the authority and political capital to make final decisions regarding the ServiceNow platform. The ‘buck stops’ with this person.
2. A Steering Committee must be defined. The platform owner should lead this steering committee, whose members are able to accurately weigh the needs of the business against the cost of current and future technical debt incurred by taking on any given customization. In order for these decisions to be made accurately, a trusted technical advisor (like your friendly neighborhood Certified Master Architect) is an ideal member to have on your steering committee.
3. The customization pipeline. Your platform architect will be made aware of any customization requests from your ServiceNow development team and Business Analysts as they document and see new requirements. Since we all are working from the same definition of a customization, this now becomes easier to manage.
4. Frequent steering committee meetings. The platform architect will bring all customization requests to the steering committee for discussion and final decision. These meetings should be frequent enough to ensure that the development process is not negatively impacted while waiting on the committee’s decisions.
5. Communication. Communication is always key, but not implementing a requested custom enhancement of ServiceNow can have major business implications. Bearing this news to the business process owner(s) who requested the customization is the responsibility of the platform owner (remember how the buck stops with this person?). The decision to not implement nearly always comes with additional organizational change management considerations, and as such needs to be well planned, managed, and delivered.

Implementing a process around the above concepts to tightly govern your ServiceNow platform and handle all customization requests will set you up for long term success by eliminating rogue BAs and developers. It will keep you closer to ServiceNow's baseline code, reduce the effort of future upgrade projects, and allow ServiceNow to be the innovators of their platform. That’s what this is all about, letting ServiceNow innovate rather than customizing yourself into a corner, making it unable to take advantage of that next shiny new toy coming out in the next release of ServiceNow.