Get away from the "out-of-the-box" box.
It seems that everyone is seeking an 'out-of-the-box' (OOB) solution these days. In fact, I cannot recall a single project in the past five years where OOB was not considered a crucial requirement. However, the phrase has become so overused that it is now being misinterpreted and misconstrued.
Here's the thing: when you purchase ServiceNow, it is already an OOB solution. There is no such thing as a perfect OOB implementation. If that were the case, ServiceNow would be plug-and-play. But as anyone who has been involved in a ServiceNow implementation can attest, that is not the reality.
Customizations of the platform are inevitable and necessary, and denying this fact is akin to sticking your head in the sand to avoid the implied work and diligence involved in managing the health and development of a platform.
This being said, do not consider this article a free pass to customize and develop in a free-for-all frenzy. No, as with all things, the transformation of the platform must be mindful.
Although customizations and technical debt should be taken into account, most organizations should question their need for customization of an OOB process like Incident Management. It's rare to find a company in ITSM that is truly unique.
Keep in mind that you are essentially on your own any time you change or make additions to the platform and its applications. The support of ServiceNow focuses on fixing broken parts of the existing system.
To be successful you must:
Understand the requirements related to the customization request.
Otherwise, you will not be able to make an informed decision on cost-of-ownership VS business value through a standard for determining if you should pursue the development of customization.
Rather than avoiding the term 'customization,' it is better to embrace and govern it.
It is important to document how and why you deviate from a process/default logic of the platform and who approved the customization.
And documentation does not start and end with a user story.
As referenced in the above article the user story is there to capture the use cases as they relate to a persona. The user story is part of a grander user journey. The development happening as a result of a prioritized user story needs functional and technical documentation that can be used for future reference by demand management, developers, and support alike.
If you require customization, it's crucial to embrace it, govern it, and document it appropriately.
A technical side note: Additionally, copying and deactivating an OOB object to customize a newly added clone of it is not recommended.
This may look better on the upgrade monitor, but it only masks the customization instead of embracing it.
2 Comments
