Tuesday, January 22, 2013

Building a IT Service Catalog in 5 easy steps

This is a bit of a brain-dump of how to build the list.  The "5 easy steps" is a sarcastic protest against formula blog writing and the stupefying titles chosen for those posts. (thanks for tolerating my protest)

Begin a list.  Use excel, it does everything you need.
Write down all the services you know about, and then expect to stumble across many more services you haven't listed.  The list gets built iteratively which lets you avoid anxiety about it being incomplete.

For each service listed in define WHAT the service is.  Normally this involves a noun like "Network services".  Describe what the service provides in terms the requestors will understand.
List the verbs that apply to the service.  These are the common changes;
"Server - Backup", "Server - Restore", "Network - VLAN creation" etc.

Under each service, list what changes can be requested.  If the changes are valid but not request-able  mark those as "internal or technical" services.

I'm going to be vague on purpose and drift from "service to change".  If you have a tiny IT shop where BOB does everything this won't make sense, but if you support 30,000 users like we do where I work, then this will fit OK.

List who designs the service. There should be a group / department, and an actual person's name.  The name is the person you talk to if you need to ask that the service be modified to operate differently.

List who delivers the service changes.  Sometimes its the designer, often a group of IT foot soldiers who follow orders.  There should be a group / department, and an actual person's name.  The person named here is the one who gets complaints about how the service is delivered.

List what pre-requisites are necessary in order to request the change.
- Perhaps there are security approvals, or budget approvals required BEFORE requesting service.
- Don't get in the habit of holding requests for service in a holding pattern while the customer disappears to get pre-requisites.

List the minimum data set that the service delivery team requires in order to successfully deliver service.
- By way of example, in our organization, for Software, we need to know; Vendor, Title, Version/edition, PCname/device, cost centre number, requestor's department.

List the expected turnaround.  If your customer knows the service is normally delivered in 10 business days, this helps set the tone so they don't start "escalating" the next day.

Link to "Standard operating procedures" that have been developed to support consistent delivery of the changes related to the service.
Link to policies your requestors will need to follow / agree to; (electronic use policies/ password policies etc.)
Link to user documentation.
List "How to access the service" beginning with "Call the service desk at 604-555-1212".
Link to any request forms you have in place to support the service and related changes.
List eligibility information if you know it;  e.g. the marking software is available to instructors and teaching assistants but not students...

Enjoy!  I hope this helps.  If you want me to post a template that might be helpful, leave me a comment below.


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.