Are you sick of hearing about Twitter yet? It is just a bunch of short little text messages, but somehow it has struck a nerve with a lot of people. At first glance, it appears to be just a fun little diversion, but some companies have found very effective ways to use it for marketing and customer support. Still, you don’t hear about IT departments, who like to be seen as innovators, hailing its benefits. But if you think about social networking/Web 2.0 tools like Twitter, they are very well suited to help solve some of the problems that IT departments struggle with the most.One of the reasons so many companies are looking to IT service management is that IT personnel are spread out across different cities and countries more than ever, and good processes can help compensate for people not sitting together. But effective processes and collaboration aren’t mutually exclusive; collaboration makes good processes better. So why not take a simple and effective collaboration tool like Twitter and use it to help improve IT Service Management Processes?
Unacceptable Production Outages
I recently worked with a fast moving financial services company that was very responsive to the needs of the business; however, because of the complex environment and rapid pace, most of the critical incidents that caused outages were self-inflicted. The frequency of these critical incidents was not acceptable to IT; much less the business. A very common approach to preventing changes from adversely affecting the business is to throttle the number of changes to a trickle. This is all too often what change advisory boards (CABs) end up doing in lieu of effectively evaluating changes.
But, what is a change really? It is a fix to a problem that is holding the business back, or, an improvement to move it forward. Faster changes with fewer unintended side effects are the “secret sauce”―they are what separate high performing IT organizations from the rest of us. I know one company that, effectively, didn’t allow changes to the IT environment during their busiest three months to prevent outages. This is no way to run a business, much less use IT to establish a competitive advantage.
An obvious first step was to implement a more rigorous change approval process, especially for the systems that the business designated most critical. Not only did we beef up the change control process, but we imposed very strict consequences for not following it. While this was pretty by-the-book, it only partially reduced the self-inflicted incidents. From time to time what people thought were minor changes still caused major problems. This isn’t surprising to anyone who has been in IT very long and has seen their share of production outages caused by changes to systems designated as “non-production”. Evaluating the impact of changes is the hardest part of the process.
What we found in our regular review of critical incidents (which I highly recommend everyone should do) was that someone in the group invariably said something along the lines of “If I knew you were going to do that I would have warned you about so and so”. The organization had the necessary knowledge but didn’t effectively share and use it. And, even when the information was properly documented, it wasn’t always found or fully understood by everyone involved in the change. We set to work on improving our knowledge management tools and configuration management documentation, but it was very obvious that these efforts would yield improvements over time and not provide the immediate improvement we were hoping for.
A Crazy Idea
While discussing our problems someone threw out the idea of using something like Twitter to help. Here I have to stop and confess: I thought it was a goofy idea. But as we discussed it we decided we could do a pilot very easily using a simple e-mail distribution list. So, there was really no cost or harm to giving it a try. Before making a change, regardless of size, people would send a very short note (a tweet) to the list describing the change and referencing the ticket. Twitter imposes a 140 character limit, and we asked people to use that as a guideline and to try and confine the message to the subject line when possible.