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.

Improving Change

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.

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.

Improving Change

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.

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.

Improving Change

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.

Why It Worked

The IT staff generally didn’t like the extra step and didn’t like any extra e-mail in their already cluttered in-boxes. But what they were asked to do was so simple and easy that there was absolutely no problem with adoption. There were later suggestions to add bells and whistles, which we resisted because we realized the simplicity of the process was what made it effective. Also, when we rolled out the pilot, we deliberately didn’t put a lot of rules in place, and we resisted subsequent urges to make it more formal.

This process allowed information to be shared by the IT team very quickly and without adding a lot of overhead―you can’t have everyone in each CAB meeting and looking at every ticket. A Twitter to the effect of “I’m going to update this server” usually went without response, but sometimes resulted in stopping or delaying the change or another course of action entirely. It was especially helpful in getting information from the senior team members to the more junior ones.

Another benefit was that it allowed us to quickly zero in on the culprit when a change did cause a problem. If your PDA stops receiving e-mail, and the last message you got was a tweet about a firewall change, you have a pretty good idea where to start troubleshooting.

The moral of this story is don’t dismiss using social networking tools to help improve ITSM processes. The technology and concepts behind a lot of Web 2.0 and social networking tools are relatively simple in comparison to what is normally found in an enterprise, so they are easy to implement compared to other tools. By definition these tools generally address the areas IT struggles with most―collaboration and sharing. And a good portion of the population is familiar with their use, so training and adoption are not big issues. And, perhaps, best of all, it's free.

This, I believe, constitutes a win-win-win-win.

Jason Druebert is a Consultant with BT Professional Services; he has extensive experience in ITSM, IT operations, and project management.