You have been saddled with an integrator’s “quickstart” and it is killing you at every upgrade
Let’s face facts…it seemed like a good idea at the time, a faster and cheaper implementation, but now you are now paying for it in every upgrade cycle. Dealing with code debt from an implementor’s update-set-based “quick start”? We feel your pain. Many customers went this route and many integrators, in the rush to give people fast and cheap implementations, created update sets that occasionally “break” during upgrades and cause customers to incur remediation time and expense when you take an upgrade.
Why is this a problem?
Herein lies the problem, many of the “quick start” program’s update sets were actually rife with code debt when you got them, were never updated by the implementation partner on your system, and are very poorly documented. Although Cask never took this approach, some of our employees worked for these firms and saw the sausage making process. These are not bad implementers, they were trying to respond to market demand. This was supposed to decrease the cost of implementation as well as make the implementation faster after all, which is why you bought it.
Managing code debt in the “quick start” and keeping the update sets current to each ServiceNow version is a real issue for partners. The struggle for these partners is that as ServiceNow versions changed every 6 or so months it became impractical to keep up with updating these update sets, testing them, and documenting them. So the focus went from using them for 80% of the install to a lower percentage of the effort and just tweaking the known issues with the update sets to using them for a smaller and smaller percentage of the implementation as code debt mounts up. Occasional efforts to refresh them were tough for the implementation community as those same resources are their primary source of billable revenue so they became infrequent. It has not been uncommon to see update sets originally written for Calgary used in Fuji implementations. Think about when you installed originally when you used a “quick start” odds are that code the integrator used was, at least in part, a few releases behind that. Since we are now looking towards London and Madrid how far behind the platform are those update sets now?
So exactly how long have those update sets just been sitting in instance of ServiceNow without being examined as a part of an upgrade process. It is very possible that you are fine, but you probably want to take a look at them and their documentation to ensure you are still able to take advantage of new features, functions, and evolving best practices as the ServiceNow platform continues to evolve.
How big is this problem?
The answer is BIG, you are not alone and this is not limited to just ITSM. Many of the large implementation partners did go this direction. They used update set based “quick start” packages to enable customers to avoid the cost of configuration within the tool for ITSM, HR Case and other modules. There are hundreds of customers out there just like you, some with this “code of Damocles” hanging over their instances of ServiceNow. Is it going to take down your instance, of course not, this is just a maintenance pain that is causing some annoyance or additional cost for you today in most cases. But costs add up and the effects mount up over time, just like in Problem Management there comes a time when your pain level gets high enough you decide to go from known error to get that fix in the change management process.
What do I do about it?
There are more than one solution to this problem of course. You know your system, your users, the teams you support, your backlog, and most importantly your budget. Take a look at and understand your ACE report and then talk to your implementation partner or ServiceNow about your instance. If you have a Platform Governance team and a ServiceNow Roadmap engage with them, if you do not see the joint ServiceNow / Cask eBook on Technical Governance of the ServiceNow Platform for some guidance. Ask yourselves some critical questions around your use of the platform and if you are being limited by your configuration:
- Are you using current best practice process and have it configured that way on your ServiceNow Platform?
- Has ServiceNow come out with a feature our configuration created though a “quick start” update set?
- Last upgrade, how much time did we have to spend in remediation due to update sets?
Gather up that data and see if there is a business case or an element of a business case for taking some corrective action around the issue.
Leveraging your governance model you can examine your update sets holistically and determine if this a small problem that can be dealt with incrementally as a part of the backlog of enhancements or if it is a larger problem. If it is a larger problem that is having real impact is there a related initiative that it can be rolled under to find some economies of scale to make it a less expensive undertaking.
Conclusions
We all look for the best solution that we can find to enable our businesses. Good, Fast, and Cheap has become a kind of holy grail that we all chase after all the time. The challenge becomes that these measures are all relative. Your goal, now that you have had the platform up and running for a few years, is to run it in an efficient (cheap) and effective (good) manner. We would suggest to you that if you have multiple issues, including old update sets, that bog you down at each upgrade you may want to consider a greenfield solution of reimplementation over trying to decompose each of your issues. Troubleshooting each of them individually in some never ending squishy cleanup project lacks the kind of impact that turns heads and allows you to turn your ServiceNow implementation into an asset of the business instead of a cost to the business. Make the leap to some of the scoped applications and a clean new Service Portal look and feel as a part reimplementation using those efforts as a catalyst and reap the benefits across the entire platform.
