Change is arguably one of the riskiest behaviors within IT. Whenever we make a change, things tend to break. It is in no way coincidental that one of the foci of change management is post-change incidents, i.e. the errors introduced by the changes we make. I would go so far as to say that the only thing associated with higher risk than change is not changing.
ITIL is an excellent framework for running IT operations. It offers tools and process management to help you improve on what you’ve got. Unlike what many consultants would have you believe, however, it is not a panacea. You cannot simply implement all of ITIL and call it a day. If you were to try, you would certainly fail.
One of my many roles at work is that of change coordinator for a large subset of our customers. I have learned a lot in this capacity, and have come to feel that, while Incident Management is the natural first step in ITIL implementation, until you start implementing Change Management, the majority of your effort is largely spent firing fires.
Ask anyone who has a glancing familiarity with Kanban what they know of it, and one of the (if not the) first things they will mention, is the use of a kanban board. This is true; the kanban board, whether physical or digital, is one of the most visible parts of the Kanban method. It is an eminently visual way to represent WIP. So, how do you implement a kanban board in IT support?
I have, for some time now, been reading up on DevOps. One thing that, for some reason, keeps coming up, is that people seem to think that there is a fundamental incompatibility between DevOps and ITIL. The more I read, however, the more it becomes clear that there is no disparity at all between them. If you have been following my blog for a while, it should be fairly obvious that I have drunk the ITIL Kool-aid. Simply put, I think any operations shop that is not implementing ITIL is doing it wrong.
When performing a task, one will often be in the position to choose either doing something quickly, or doing something right. In many cases, either example is fine, as the job gets done satisfactorily. Still, I believe that you are better off with doing it right each and every time. Now, before you think I am preaching about my own level of perfection, know that this is not the case, and that I fail to do this more often than I would like to admit. This is not an admonishment; it is a level to which I aspire.
The first time I worked IT support in a professional setting, I was seventeen years old. I had gotten an internship (one day per week) with my uncle’s firm as part of my third year of vocational training, and spent a day per week with them. In the beginning, I was mostly hanging out with the IT staff, not really providing much of any use to anyone.
A while back, I participated in a discussion about the application of Kanban in an IT Operations setting. Here are some of my thoughts on the matter:
CSI – that’s Continual Service Improvement, by the way, not Crime Scene Investigation – is, to my mind, the single most important stage in the ITIL service life cycle. It evaluates what has gone before, identifies areas for improvement, and aids in the implementation of improving. In an ideal situation, CSI informs all the other stages, and is the main driver for the service life cycle.