We configured it to be just like the old tool
Your team had a favorite tool, you tried to recreate it in ServiceNow and now you’re paying the price. We wish this scenario was less common, but realize the difficulty in explaining to management the need to retool their processes to better align to the flow of the ServiceNow platform and best practice. After all, you bought the tool to solve “our” problems didn’t you? People think that the tool – and the tool alone – is the answer but, if that was the case, you would have accepted the tool in ServiceNow out-of-box and not tried to contort it into your old one. Here at Cask, we believe that your people – following a consistent process, enabled by a well configured tool and supported by your internal management & culture – are what actually get work done. But in this scenario, your tool implementation has been weakened by your configuration of it and your team is forced to to pick up the slack. Luckily, there are several strategies that can help you.
It seemed like a good idea at the time
When you made your configuration decisions, you did so with a limited experience of the ServiceNow platform and a lot of pressure to implement successfully. Your team was used to working a certain way and recreating that way in ServiceNow seemed like a good idea given that magic combination of time and money. But change is tough, after all, and the change in tool is tough enough – right? So, to minimize that change, you kept processes the same and allowed your team to work the same way in the new tool as they had in the old. And, though it minimized training costs and the pain of the change at the time, you’re realizing that there are some opportunities to improve process and reduce costs by getting closer to a baseline configuration of ServiceNow.
How we get this done
Best practices evolve over time. ITIL isn’t dogma, it’s a collection of best practices and is meant to be molded. Think about it, if your company is in the manufacturing business, would it be acceptable to do the same thing, the same way, for the same cost for years on end? Probably not. The same is true in IT service management. You moved to ServiceNow to take advantage of the service management evolution the platform made possible. Now, let’s figure out how to get you back closer to baseline and make the tool the rock solid foundation that it can be. The trick is to make the business case for “updating,” “refreshing,” “tweaking,” “maintaining,” or “enhancing” your ServiceNow instance to better align with ServiceNow best practice while avoiding the stigma of “having done it wrong.” You didn’t do it wrong – you did what you could at the time with the means you had.
If you have accidentally fallen into this trap, the key is to start with the ServiceNow Platform Architect function in your ServiceNow Platform Governance Plan. Make no mistake – this is not an install-it-once-and-patch-it-occasionally piece of software circa 1996, this is a robust cloud-based platform that can revolutionize how you work. And this doesn’t just pertain to IT but to anywhere in your organization where structured work exists. It needs a governance team, standards and a roadmap. A key element of that is the ServiceNow Platform Architect function. This key function sets your standards around how you technically govern the platform. It helps to answer key questions regarding when to configure and customize as well as determining what valid technical reasons are for deviating from the standard configuration of the tool. For more information on this, see the jointly-developed Cask & ServiceNow “Governance, Technical Best Practice” eBook. The ServiceNow Platform Architect function can help you determine what you need to change and what can stay the same and fit into your complete platform governance structure to help plan the when to make these changes.
Your second step is to look at the process side. Management loves continual service improvement because it leads to measurable results in the mystic triad (Better, Faster, Cheaper) that we all chase. Your goal in this effort is to remove any process elements that force the tool – or your people – into some kind of unnatural act while you are trying to do the work. Your Process Owners and/or Application Owner(s) need to pull their teams together periodically in order to effectively govern those processes and applications (ServiceNow HR Case & Knowledge Management are examples of non-IT processes). These process teams need help, though – both regarding what the tool normally does and what the industry best practice in the area is. Just like you need a ServiceNow platform roadmap to assist in structuring improvements and platform maintenance, you need a process maturity roadmap for each of your processes (stay tuned for an upcoming blog on this topic). Bring in ServiceNow or a certified ServiceNow implementation partner to help you examine what you need to do in order to get back to a standard configuration and help take the burden off of your people.
When to do it?
You need to have a roadmap and adher to it unless conditions change because planned and logical change is the best approach to a successful outcome. As with many things, you are forced into a choice: do I do this as one big bang or as an incremental set of changes? There are pluses and minuses of both approaches from technical, process-improvement, political and cost perspectives.
If you are going incremental, the logical time to do these changes may be as part of a ServiceNow version upgrade. This requires some planning and patience as you want to time specific efforts to get back closer to standard with the enhancements that ServiceNow makes to those modules. At that point, you need to be in the guts of your instance and testing to some degree, anyway. Those elements add to your business case (see the next section) by reducing the cost of reimplementing under the guise of a budget item you were going to take on regardless. Of course the downside is that, although you are meeting the Good and Cheap tests, you are going to fall short of the Fast test on this one. It will likely take you 18 months to get back to a standard configuration.
Ripping off the band-aid or the big bang (not to be confused with boiling the ocean approach) may be reasonably Cheap while meeting the Good and Fast tests. You may now be thinking that I am a crazy consultant here, but hear me out. You have something now that you didn’t when you first implemented ServiceNow: data and evidence. You have measurements at every step of the work that can be compared to the desired future state. This allows you to build the business case that can then help you convince management to take the big bang approach. Big bang has the advantages of a “fresh” look from a political perspective.
Now what? The Business Case
There are ways to leverage your learnings since your initial ServiceNow implementation and build that internal business case – evidence-based management makes much more sense than guessing, after all. So here are some costs you should consider when making the case:
- Labor manage customizations during ServiceNow upgrades
- Labor savings due to improvements in the process workflow
- Cost avoidance because of decreased professional service costs
- Improved end user / customer satisfaction due to process improvements
- Benefits of faster resolution or service delivery times (end user productivity)
- Benefits of better reporting by being better aligned to out-of-box functionality
- Decrease in training times / better ability to scale due to reduced customization
While some of these are soft costs and, as such, are generally discounted by management, they help tell the story. In a large enterprise, the hard cost savings alone can add up quickly. Remember, the law of large numbers works for you here. If you can shave $1 in labor off of each incident in a 10,000 annual incident organization, that amounts to $10,000 in labor. That $1 in labor is 1 minute and 54 seconds for a $60,000/year employee at a reasonable burden rate of 1.35x. Remember also that there will be costs associated with each approach – incremental and big bang. Capture and compare all of them to give yourself the best possible business case for your management team.
Conclusions
In managing the change, the business case is key in determining which approach is better for your organization. But don’t let it get in your way. You need to make sure you are aligning to ServiceNow technical and business best practices in your platform configuration. Develop and implement a roadmap that includes a continual service improvement cycle for each of your processes and ServiceNow applications. Reimplementation is a viable option for some customers who tried to recreate (pick your tool) in ServiceNow, but make an informed, mindful decision and don’t hesitate to ask for help and advice from a knowledgeable and experienced ServiceNow partner.
I think organizational change management should be included in this conversation. Even if you have a platform architect and the organization is not willing to change the way they work so they align with what SN does baseline or with minimum configuration changes, you will still end up in “customized” version of the platform.
Gain the tools to create a governance foundation that is scalable and easy to manage with ServiceNow’s Governance Best Practices.
