I need a mulligan

[britta]

This is the fifth in my project management series.

As many of you know, a mulligan is when a golfer is allowed a second try after a particularly bad shot. Plus, the initial try is not marked as a stroke on the scorecard. When it comes to ServiceNow, some customers would like a do-over. In a previous life as a ServiceNow customer, I led a mulligan in 2008. 

Once the company decided to move from TrackIt to ServiceNow, a consulting firm was selected to assist with the project. Our Director of Networks was appointed the lead, and he then assembled a team, which he tried to limit in size so as not to slow down the project. The consultants held many meetings where we talked about processes and future state. The consultants also created a lot of documentation—swim lane diagrams, read outs, etc.

We were also told that all of us needed to become ITIL certified, which everyone dutifully did. However, like most people who have passed ITIL exams, we learned it’s only a framework; it's not prescriptive. Decisions still needed to be made. I tried to raise concerns along the way, but I was brushed aside. So, the team moved forward with a very 1990s approach to help desk, not even a service desk concept.

We went live in January of 2008 with minimal testing, training, or organizational change management, and it did not go well. By late February, I was asked if I could "reset" ServiceNow—just me, by myself. Since I have always been passionate about our platform, and I suffer from hero complex, I said, “Of course.” 

I started by reaching out to all the stakeholders who were to use the platform in addition to IT: HR, Finance, Sales, etc. I got feedback on what wasn't working for them. Then, I complied the feedback and looked for patterns and quick wins. My biggest battle was with the help desk manager who wanted to do an old fashioned, five-tiered categorization system and not use configuration items (CIs). I finally won him over, and we went with three layers of categorization with one of them being CI "lite" as we did not have a real CMDB. 

These changes made filling out incident forms easier, which made end users happy, and made reporting more straightforward, which pleased management. I effected some other changes, and then had users do user acceptance testing (UAT) to find defects. The first release had not included user testing. Finally, I was prepared to go live again. 

However, unlike the previous launch, I held many training sessions with end users in advance to get them comfortable with the platform. I also created and distributed training documents, and I had an aggressive organizational change management campaign that focused on the “what’s in it for me” for the users and helped get their buy in. 

Post-launch, I sent out tips of the week to help everyone continue to learn how to use the platform. Another thing I did was conduct additional training.

When I wrangled the money out of my manager to go to ServiceNow’s Knowledge conference that year, I had my 15 minutes of fame as I was known as the one who saved ServiceNow at my company. And they are still on the platform today.

What made ServiceNow "sticky" the second time around? First, it was about having a team that truly understood the problem needing to be solved and had empathy for the product’s consumers. The Director of Networks did not know service desks, nor did he have much emotional intelligence. 

Second, the right stakeholders were involved, and their input was taken seriously. Many organizations feel that limiting the number of stakeholders involved will streamline decision making, but in my experience, I've seen it create problems during UAT. Those who felt disenfranchised will use testing to bring up defects in the minutiae. That is when it becomes clear that the system has not been configured with the end users in mind. It often leads to rework and a delay in go live.

Third, training was done in advance of go live, so users could know what to expect, ask questions, and provide feedback that could be taken in consideration for the next release. The users also got mini manuals with step-by-step instructions and screenshots for key tasks. Training the day before, or day of, is not a great user experience. It takes time for people to adapt to change.

On that note, organizational change management was another key part of the program. I've worked with many customers who couldn't wait to get rid of their existing platform, but when it got closer to go live, they wanted what they had in the existing system. That seems like a head-scratcher, but when you realize how difficult change really is for most people, it completely makes sense. When it gets closer to go live, people want to go back to what is familiar because that feels less scary. Selling the “what’s in it for me” successfully will ease the transition to the new platform. 

Keep these concepts in mind, and I hope the only mulligan you’ll need is for your golf game.