My Role
I acted as the Technical Program Manager that eventually became the team lead for the technical team that implemented ServiceNow.
Context
When I came to LivePerson, ServiceNow was already there in some capacity. It was dreadfully underutilized. During this same time, the entire technical organization was struggling with tracking incidents, calling in the right people when issues happened (people would pick up a physical phone and call their friends .. yea, it was like that), and changes were tracked semi-regularly.
There were a few ServiceNow champions who wanted to utilize the tool more. We collected all those champions together and put this project together during an offsite in Seattle.
The team of champions was later formalized into a dedicated team that manages our ITSM process, Business Operations.
What we did
- We sat down in Seattle and soberly addressed the problem. We started to put together ideal solutions (agnostic of tooling). We needed 2 things coming out of that meeting - Executive Sponsorship and a Planned Roadmap.
- For Executive Sponsorship, we put together a quick demo for our leader on our vision of Incident Management at LivePerson. During the presentation, we cheekily loaded all our phone numbers into ServiceNow and set our phones to mega loud. When we created the incident, we had an automated process call the phones of the presentation team (that was strategically placed throughout the board room). They loved it and we were sponsored with the budget to implement this system.
- For the Planned Roadmap, we collected use cases from our NOC, Support, Engineering teams, and executives. These use cases helped us understand what were the most common painpoints that we could solve immediately.
Difficult problems we encountered
Problem | Solution |
Getting an organization for 1000+ engineers to align on a process and solution. | I’ll admit that this was never fully solved. But this was a continuous effort of training, designing self-guiding UIs, robust documentation, and a LOT of course correction. |
Once a few use cases were built, more people wanted the tool to do more. | This was a good problem to have. More people wanted to build on top of ServiceNow. But we only had a limited number of people.
We created a ‘Goldilocks’ calculation that helped us prioritize in a data driven way, we published our roadmap for everyone to see, we held monthly prioritization meetings where stakeholders could provide feedback on our roadmap, and published a very detailed changlog of what we were implementing. |
ServiceNow UI sucks | There are a lot of ‘pretty’ tools on the market, and at the time, the ServiceNow UI was just terrible. It felt like a dated and archaic system.
We deployed different views into ServiceNow like Service Portal and the SNOW Workspace to ease the pain of using the tool. We had continuous design reviews to reduce the number of fields in our forms and created easy-to-follow dashboards. |
Lessons Learned
- Tooling like ServiceNow that enforces process is not a one-time implementation, it’s a continuous process to work on the tool and make it work how you want. You need a team to focus on this. Stop pretending that this can be someone’s part time job. Salespeople won’t be upfront with you on this, but you need people focusing on the tool.
- Be very clear about what is in-scope for the tool. We’d often get requests to implement very custom workflows that did not fit into the product. Don’t make your tool confusing, make it purpose built.
- Use Out-of-the-box features as much as possible. We overly customized our tool at the start because we had shiny-new-toy-syndrome. Keep it simple and don’t customize just because you can. It limits your ability to support the tool at scale.
- Build good relationships with your vendors. The more you pay, the more they’ll be willing to be flexible with you and help you get out of tight spots. ServiceNow has been an amazing partner for us and extremely attentive to our needs because of our relationship.