Posts Tagged ‘ITIL’

Those historic words were the beginning of a thriller that lasted a couple of days and where process (and service) management beat the mathematical odds of life and death.

For those who have no clue what I’m talking about, see the classic movie (Apollo 13 featuring Tom Hanks and on VT4 this Friday).

And although ITIL, Service Management and the likes still had to be invented/discovered (this story happened in 1970 were ITIL came into play after the Falkland war in 1982), it is exactly the ITIL Foundations that saved those men (probably helped by a good guardian angel).

A dutch company (Gaming Works) has used this theme in a great simulation game for companies.

– The game is fun to play and experience learned me that even the most reluctant participant gets caught up in the action and is very soon deeply involved in making sure the astronauts are saved.

– The game is all about teamwork, communication learning and (process) improvement. This makes it the ideal combination between a team event (HR) and a training.

– Because it is a simulation, the people involved are drawn away from the day-to-day organization, hierarchical structures and sometimes even their own inhibitions. This often leads to open and profound discussions about processes and the way they are being followed/used. Of course this reflects the issues, frustrations, pitfalls and opportunities of the real world situation, making the game an excellent learning experience for the people involved and their management.

– The game introduces process and service thinking (ITIL V2 or V3, ISO 20000) without any need for prior knowledge or understanding of these frameworks. Hence it is an ideal ‘get everyone on the same page’ exercise to help overcome resistance when introducing Service Management in your organization.

– Oh and did I already mention that it is great fun !

If you are interested or want more info, do not hesitate to contact me.

ITIL is owned and registered by the British OGC
Apollo 13 an IT Service Management simulation game is owned and registered by Gaming works bv, The Netherlands.












Maybe not perfect…but this is how I see the interaction between project and the support processes. There shouldn’t really be a conflict or issue… it is possible to align them neatly.

These days, most companies rely on IT and IT infrastructure to support part or all of their business. Therefore the need to fix major incidents is becoming more and more pressing, since companies tend to lose money when services are down.

Most companies also have change and release control in place, which balances stability vs flexibility in their organisation.

Emrgency changes and the emergency change process (ECP) are then what reconciles the urgent need for an immediate fix (read change) versus the control and management required for normal change.

In an outsourced environment there are some more parameters that will complicate the matter. Who will authorise the emergency change? how is it charged?

I’ve seen several companies that have defined the ECP as ‘fix now, do all change steps later’. This (almost) always is a certain path to disaster. Furthermore there is no framework or best practice that tells you to do this… And you are opening the door for a specialist to change the IT environment whenever he feels like it, (ab)using the Emergency change as the means to get things done.

So, how to cope with this?
The easiest way to deal with this is formalize the Emergency change Process for each critical service or system. This ECP will list the criteria to invoke it, who will be on the crisis team (including a contact list with backup/escalation), and what the steps to be taken are (eg. minimal testing requirements). Defining these is usually done with the release of a new service or system.
The biggest advantage is that there is little room for discussion…The rules are set (and agreed with the business).

After the change has been implemented, a formal handover to the CAB of the change needs to be done, in order to ensure that:
– Everyone is aware of what exactly was changed
– What the impact is of the implemented change on other systems and/or services
– what the impact is of the implemented change on other ongoing changes/releases
– we know what could have been done to avoid this (lessons learned)
– make sure we know what the current version/state of the production environment is
– asses the need for the emergency change

I also advice to launch a problem (after the implementation) to make sure the RCA of the incident has really been handled.