Tuesday, January 22, 2013

Getting to ITIL - Where to start

When undertaking a quality program like implementing the ITIL (IT Infrastructure Library), it can be tempting to try to "do everything".  ITIL is particularly beguiling in this respect since pretty much everything it suggests is reasonable, important and such a gosh darn good idea.

I mean, we want to be able to manage incidents right? and to control changes, and to have a service desk, and to fulfill requests, and to manage capacity and to.... the list goes on.  On the one hand there are more problems to solve than staff to solve them (or hours in the day) on the other hand there are so many good opportunities, you basically can't lose, any improvement at all is useful.

The question is; "where to start?"

While I'm sure the answer depends on your individual situation, in my experience and from my conversations with other IT professionals, there seems to be a common pattern.

In a way it resembles medical triage.  Triage originated in World War I with French doctors treating the battlefield wounded at the aid stations behind the front.  They divided the wounded into 3 categories;

  • Those who are likely to live, regardless of what care they receive;
  • Those who are likely to die, regardless of what care they receive;
  • Those for whom immediate care might make a positive difference in outcome


In the same way, there are areas of ITSM where;

  • service will continue on without intervention;
  • service or circumstance is so broken that available resources cannot remedy the situation;
  • service can be significantly improved through intervention.

By applying triage as a model, effort is applied where it will do the greatest good.

PRO-TIP: Your IT staff are smart and usually see these areas of greatest opportunity.  Their pain. (sometimes cleverly disguised as complaints) will highlight items that need to be addressed (first).

In another way it resembles the discipline of fire-fighting.
Firefighting is a field that has gone from willing volunteers in ties and suits smoking cigars who showed up with their buckets to "bucket brigade practice", to an age where we have embedded fire-proofing in every building code and consequently every building in North America (and beyond).  The concrete firewalls, the sprinklers, the pull stations, the crash bars on exit doors, the exit signs, the fire marshalls, the extinguishers by the exit, the public annunciation systems.  By designing buildings so that they don't burn (easily) and by planning so that people can survive, we live in a totally different era, one where homes and businesses don't get lost to fire so regularly.

So, as with firefighting, in IT;
1. Put out the fires. Incident management provides response capabilities.  Without the ability to respond in a planned and appropriate way, IT organizations are so disrupted by unmanaged incidents that they can't function effectively.
2. Stop lighting new fires.  Change management is many things but in a nutshell it is about controlling the changes that are made to the infrastructure (and systems) in a production environment so that the randomness of uncontrolled changes don't disrupt service.
3. Plan fire prevention, Take stock of the existing fire hazards and make a list of the most pressing / dangerous ones.
4. Start fire proofing.  You have a plan. Work that plan.

PRO-TIP: Start light!  Nothing scares away talented staff more than making them follow a process that is too heavy.

Thanks for listening.  I wish you success as you make things better and improve the world :-)
Greg.

No comments:

Post a Comment