A Change is Still a Change

One recent thing we are struggling with is the idea of setting changes up on an "automatic" schedule. For example, setting a cron job on a production server to apply OS patches and reboot the server. While this may prevent the technologist from being up at 2am during the maintenance window, it does not get around needing to submit a normal change request.

There was a miss perception that setting up "automatic" jobs somehow got around the need to submit a change request. It's something we have to remind people of fairly frequently.

Our current software is custom built and does not yet support recurring change requests. Hopefully we can get the time to code that in so we can help make the daily work lives of our technologists better!

Emergency Change - Rant of the Week

It is always fun to get emergency changes and sometimes they leave you shaking your head.

Emergency Change Reason: Classroom switches to be replaced that are currently not in use, but will be when school starts.

Background: To proactively replace old switches with the potential of dying and causing an unplanned outage.

I am not sure this rises to the level of an emergency, but lets consider it for a moment. The first thing is the "Emergency Reason" and while it is great that the switches are not in use, it does not really say why this is an emergency. That is alright, lets read further and see if the "Background" indicates what could be happening. No, not much in the "Background" section other than replacing old switches.

These types of change requests need more information for the CAB to make any sort of realistic decision. Of course, then the CAB is perceived as being nit-picky, but seriously.

I am not advocating lying to the CAB, but at least make it sound like an emergency. Perhaps the switches are throwing errors or maybe they are physically falling out of the racks. Who knows! The point is that the CAB needs to help educate people on what they need without being perceived as being nit-picky or overbearing. I find myself using up a lot of my banked "goodwill" with my peers over CAB issues. Looks like I should start investing in doughnuts and coffee to help replenish!

Basic Change Workflow

We used this graphic to walk our Interim-CIO through the basic change management process. We tried to present ITIL without a lot of technical jargon, but it was difficult since one benefit of using a service framework is to standardize on terminology.

ITIL @ UWM Training

In times of tight budgets, we could not send all of our staff to "official" ITIL training. So we offered up some home grown training to get people accustom to the basic tenets of ITIL and the phases. They produced 3 short video tutorials that briefly discussed the phases (strategy, design, transition, operation & continual service improvement) of ITIL. The videos were followed up by in-person training to do a short review as presented by one of our foundation certified staff and it also focused on one of the first things we went live with, change management. Which is where I come in. I participated in all of the training sessions to talk about our process. 

The training participants were broken in to small groups who got to review a mock change request and act as a change advisory board (CAB). It was fun to hear the discussions of some groups where members were already using our Change Tracker tool. Many of the biggest critics of the process and CAB feedback were the toughest critics of the mock change request nit picking even things the CAB would let slide.

So in general, here are the main points from my part of training:

1. Change Management is not about being an arbitrary road block to getting work done.
2. Change Management is about reducing risk in complex environments and improving communication.
3. Our change management process is working and provided an example.
4. Stressed the need for open and honest feedback on the process.
5. Fill in the rest later...

Marriage of ITIL Process and Project Management

This is a "conversational" diagram that was put together during a series of hallway discussions with one of the project managers. It was meant as a conversation chart of integration points for project management as we try to bring our PM office into the ITSM folds. This chart reflects our low organizational maturity with our ITSM/ITIL initiative.